Why you should never use Socket.IO | Hacker News Reader

Why you should never use Socket.IO

github.com

41 pointsalexhultman25 comments

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"

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

I didn't flag the post.

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.

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

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...

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

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.

I'm the one proposing the switch in WebTorrent, you can read about the decision here: https://medium.com/@diegorbaquero/%C2%B5ws-as-your-next-webs...

I use it in production (BTorrent tracker) with 700-1300 peers active 24/7. 50MB or less RAM usage.

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.

µWS is not a Socket.IO killer. In fact, you can use µWS as the low-level engine in Socket.IO.

Sadly I cannot (yet) present the pub/sub benchmarks of deepstream.io vs Socket.IO but I promise you: it will be hilarious.

Other projects that have been shown to outperform Socket.IO include SocketCluster, which use µWS as the default engine.

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

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.

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.

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?

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).

Always had WordPress as the top for that in my mind.

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.

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.

It looks like µWebSockets has bindings to Node.js. This is good to know.

I can second this. I spent 2 months fielding bug reports against ShareJS all caused by terrible design mistakes in socket.io. I ended up being forced to write my own long polling library[1] just because of how unstable socket.io was.

But today anyone building new applications should use websockets. Browser support is excellant, speed is great, firewall penetration is fantastic if you run your site on HTTPS. You gain cross-server language compatibilty, you avoid socket.io's awful design decisions around reconnection, error handling and code quality.

[1] https://github.com/josephg/node-browserchannel

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

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.

Reply on news.ycombinator.com