4 ms·

Why you should never use Socket.IO

41 points by alexhultman 10y ago

sotojuan 10y ago
Good post, but will sadly go unseen due to elections. Will try to share it once things calm down!
- alexhultman 10y 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.
- rb666 10y ago
  Socket.IO is the trump of websocket implementations. Utterly slow in the head, but widely popular somehow.
  - alexhultman 10y ago
    This is what happens when a GitHub repo accumulates critical mass: people just follow after with no critical thinking. It's like the emperors new clothes.
  - abrown28 10y ago
    By that analogy the leading contender will steal my wallet and escape prosecution because of who their friends are.
nikkwong 10y 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?
- alexhultman 10y 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 10y ago
    Always had WordPress as the top for that in my mind.
  - sova 10y 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.
    - alexhultman 10y ago
      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.
  - zappo2938 10y ago
    It looks like µWebSockets has bindings to Node.js. This is good to know.
  - josephg 10y 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 https://github.com/josephg/node-browserchannel
boylove142 10y ago
Can I have opinions from someone who have already used this?
- trakout 10y 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 10y 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-websocket-library-d34209686357#.jb27ng2gd 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_good 10y 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.
- alexhultman 10y 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.
- josephg 10y 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 http://caniuse.com/#search=websockets
  - always_good 10y 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.
    - josephg 10y ago
sova 10y ago
I appreciate there's a drop-in replacement line for existing socket.IO apps. Thanks for making something awesome
Sacho 10y 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"
- alexhultman 10y ago
  You don't consider a 60x performance overhead reason enough? And yeah, thanks so very much for flagging this post!
  - Sacho 10y ago
    I didn't flag the post.
  - evv 10y 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 10y 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-from-the-outside-world http://socket.io/docs/rooms-and-namespaces/#sending-messages...

41 points by alexhultman 10y ago

sotojuan 10y ago

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

alexhultman 10y 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.
rb666 10y ago
Socket.IO is the trump of websocket implementations. Utterly slow in the head, but widely popular somehow.
- alexhultman 10y ago
  This is what happens when a GitHub repo accumulates critical mass: people just follow after with no critical thinking. It's like the emperors new clothes.
- abrown28 10y ago
  By that analogy the leading contender will steal my wallet and escape prosecution because of who their friends are.

nikkwong 10y 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?

alexhultman 10y 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 10y ago
  Always had WordPress as the top for that in my mind.
- sova 10y 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.
  - alexhultman 10y ago
    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.
- zappo2938 10y ago
  It looks like µWebSockets has bindings to Node.js. This is good to know.
- josephg 10y 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 https://github.com/josephg/node-browserchannel

boylove142 10y ago

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

trakout 10y 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 10y 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-websocket-library-d34209686357#.jb27ng2gd 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_good 10y 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.

alexhultman 10y 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.
josephg 10y 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 http://caniuse.com/#search=websockets
- always_good 10y 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.
  - josephg 10y ago

sova 10y ago

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

Sacho 10y 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"

alexhultman 10y ago
You don't consider a 60x performance overhead reason enough? And yeah, thanks so very much for flagging this post!
- Sacho 10y ago
  I didn't flag the post.
- evv 10y 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 10y 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-from-the-outside-world http://socket.io/docs/rooms-and-namespaces/#sending-messages...