
Why you should never use Socket.IO - alexhultman
https://github.com/uWebSockets/uWebSockets#benchmarks-table---validate
======
Sacho
I like the library but the title is pure clickbait. I expected an article
arguing this position, not a github repo. The github repo simply does not
explain why "you should never use Socket.IO" \- performance is not necessarily
the only feature Socket.IO offers, it could be API surface, etc..Socket.IO is
also two parts - a client and a server, and this library is just a server.

The title is doubly worse because it doesn't actually promote the library. You
could quote the repo instead - "mWebSockets - a lightweight, efficient &
scalable WebSocket server"

~~~
alexhultman
You don't consider a 60x performance overhead reason enough? And yeah, thanks
so very much for flagging this post!

~~~
evv
If there is a 60x performance difference, why not put that information in the
title? The title doesn't even mention uWebSockets, and it is clearly your
intention to promote it. In the future, please avoid using link-baity titles
like this on HN.

The reason I've selected socket.io for projects in the past is because of the
awesome documentation and slick marketing, not because of snarky attacks on
other libraries.

------
sova
I appreciate there's a drop-in replacement line for existing socket.IO apps.
Thanks for making something awesome

------
sgrytoyr
The killer Socket.IO feature for me is being able to talk to clients from
other server processes using socket.io-redis and socket.io-emitter [1].

Any ideas how we can achieve something similar using µWS? I guess using it as
the engine in Socket.IO would do it, but let’s assume we want to get rid of
Socket.IO entirely.

[1] [http://socket.io/docs/rooms-and-namespaces/#sending-
messages...](http://socket.io/docs/rooms-and-namespaces/#sending-messages-
from-the-outside-world)

------
boylove142
Can I have opinions from someone who have already used this?

~~~
trakout
Sure. The only thing SocketIO really has going for it is built-in support for
falling back to long polling (for browsers that don't support websockets).
That said, if you're using socketIO in production, you'll have to deal with
memory leaks that aren't your fault (eg. even if you stick to boilerplate
code). If you just want something quick and easy for a hackathon or personal
project that you never want to scale, go for it. Otherwise be prepared for a
rewrite, or increased hardware costs.

------
always_good
Hard to take a "socket.io killer" seriously when it doesn't even implement
bare necessities like message_id callbacks:

    
    
        socket.emit('msg', 'hello', (err) => ...)
    

At which point the nice part of using socket.io is that there are a variety of
clients (and server impls) so every one of your users doesn't need to
implement things like message_id callbacks.

~~~
josephg
That can be implemented with a simple switch statement. Or using node's built
in eventemitters in two lines:

    
    
        const e = new EventEmitter();
        socket.on('message', msg => e.emit(msg.data.type, msg.data));
    

Also websockets have far better server and client support. There's websocket
implementations in basically every major language as well as most popular load
balancers on the market today.

When socket.io first came out it was very needed. But now websockets are
supported in all major browsers, including mobile:
[http://caniuse.com/#search=websockets](http://caniuse.com/#search=websockets)

~~~
always_good
I'm not sure what your snippet is demonstrating, but it's not demonstrating
message_id matchup.

The client stores its own message_id -> callback mapping, it has to send some
sort of reply id for the server or agree on some other mechanism, and it's not
something you want to have to build on every project, just like exponential
reconnect backaway.

And I'm not sure why you'd want to use the native WebSocket API by itself
except on toy apps.

~~~
josephg
You're talking about a light layer on top of websockets to implement a
request/response protocol. This can be done pretty trivially on top of
websockets in dozens of ways, though if what you want is request/response you
should consider using HTTP directly.

You never have to "build it again for every project" if you put your code in
npm. But I guarantee you there are dozens of libraries like this in npm
already. (Just like there are dozens of libraries to do exponential reconnect
backoff.)

The right approach is to build / use light layers on top of websockets to
solve these problems. Socket.io is the wrong solution. Its the wrong solution
for _every_ problem.

------
nikkwong
Care to share why Socket.IO is so poorly implemented? It seems to be a small
wrapper around the socket protocol—what could be written so poorly?

~~~
alexhultman
My keyboard would wear out if I listed everything wrong with Socket.IO. Simply
put: it is one of the worst pieces of software I have ever stumbled upon. And
the ratio hype-to-quality is off the charts. It's success lies in the fact
that most users don't check their numbers and simply follow what everyone else
is doing. Combined with the marketing of being "the fastest" which logically
means "there exists no such solution in any universe, that outperforms it".

I would recommend WebSocket++ or libwebsockets (if you are not going with
µWebSockets).

~~~
sova
Socket.IO came out years ago. Yes, it is slow compared to recent
implementations, but it's still valuable to give props to your predecessors.

~~~
alexhultman
WebSocket++ was written at the same time as Socket.IO and performs about 30x
better. I give credit where credit is due. I also criticize projects where
criticism is due.

------
sotojuan
Good post, but will sadly go unseen due to elections. Will try to share it
once things calm down!

~~~
alexhultman
Thanks, I just finished the Socket.IO benchmark and wanted to show my findings
(both in relation to my own project but also in relation to the existing
alternatives) Socket.IO is simply a tremendous fuck-up no matter what
perspective you have.

