- Built in reconnection.

- Events / actions as main abstraction.

- Support for degradation for old devices, browsers, corporate networks.

- WebSocket is not very good at multiplexing. One discrete TCP connection per socket (opposite direction of what HTTP/2 is going)

- Binary support inside JSON (`Buffer` etc)

Plus, all of this is requires support on the server end as well as the client.

A lot of people look at SocketIO as a client-side only library, but it's not. It has connection implementors written on the server side to support things like multiplexing over one channel.

i actually went through this debate a few days ago when deciding what to use for realtine updates on our new platform. I had previously used socket.io but decided I'd try just using straight websockets and not bothering backporting realtine updates to IE9. Really great decision IMO. The basic Websocket API is actually really easy to use. i got everything up and running in less than a day, the server is less than 100 lines, and the client side code is about 50 lines and completely resuable and DRY wherever i need realtime updates. Compare this to the 100kb (minified) and all sorts of boilerplate you have to write for socket.io, so in my opinion you're better off with straight WebSockets these days.

See this: https://gist.github.com/zeusdeux/5491cff541fb4ac4c142 I myself prefer the extra 100kb if I receive in exchange a more robust client/server architecture with browser fallback.

That link mentions that it's both a server and a client, which made me realize i didn't mention what i used server side. I used https://github.com/sitegui/nodejs-websocket/blob/master/READ... which is extremely easy to set up and use. i don't doubt the value of socket.io but I for my purposes it was not optimal.

> and the client side code is about 50 lines and completely resuable and DRY

Were you able to implement auto-reconnect with backoff? That's one of the most important features that something like Socket.io gives you.

If you don't need fallback to HTTP, there are some alternative libraries that handle auto reconnect for pure WebSockets:

https://github.com/fanout/websockhop

https://github.com/joewalnes/reconnecting-websocket

Also, if your traffic is basically one-way like in this example, don't forget Server-Sent Events, which are auto-reconnecting and well supported.

Right now just a 3 time retry with hard coded delay between each one.

i recently made a messaging app something like appear.in using websockets in less than a day. Just added nodejs cluster support to it. Kind of easy to learn and easy set up made me love websockets.

Isn't graceful degradation (in support of older browsers) the main feature of Socket.io?

Does anyone really care about IE 9 any more, though?

It's also important to note that you don't just need browser support. You also need support in every web appliance that the request passes through.

It's really common for web sockets not to work through corporate content filters and old load balancers.

It really depends on your target audience who will be using your application.

If you can block them (ie: the user needs to login), you don't need to wrory.

Apparently they make up ~7% of internet users. So my guess is, yes.

> Does anyone really care about IE 9 any more, though?

Not Microsoft. It's unsupported as of 2 months ago.