Hacker News Reader

Comment by nikkwong | Hacker News Reader

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?

View on HN

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

Reply on news.ycombinator.com