Why you should never use Socket.IO

https://github.com/uWebSockets/uWebSockets#benchmarks-table---validate

by alexhultman • 10 years ago

41 23 10 years ago

sotojuan• 10 years ago

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

alexhultman5• 10 years ago

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.

nikkwong• 10 years ago

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?

alexhultman5• 10 years ago

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

h1d• 10 years ago

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

sova2• 10 years ago

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.

zappo2938• 10 years ago

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

josephg3• 10 years ago

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

boylove142• 10 years ago

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

trakout• 10 years ago

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.

diegorbaquero• 10 years ago

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.

always_good2• 10 years ago

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.

alexhultman5• 10 years ago

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

josephg3• 10 years ago

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

always_good2• 10 years ago

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.

sova2• 10 years ago

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

Sacho2• 10 years ago

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"

alexhultman5• 10 years ago

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

Sacho2• 10 years ago

I didn't flag the post.

evv• 10 years ago

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.

sgrytoyr• 10 years ago

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

Why you should never use Socket.IO

Related Stories