I like the sound of SockJS. I wanted to use WebSockets in my HTML5-based app but shied away from socket.io because the library was so big (and my requirements were so small).
Once I implemented it I realised that Chrome and the iPhone browser use different versions of the WebSockets protocol, so it was impossible to debug in the browser. Sounds like SockJS might help with that.
To some extent yes: aesthetics are an important difference :)
Functionally you can do the same things on Socket.io as SockJS (but not the other way around).
Socket.io provides high-level messaging abstractions, including really-high-level things like clustering with the redis backend.
SockJS is only providing a WebSocket abstraction. SockJS has a well defined on-the-wire-http-fallbacks protocol: https://github.com/sockjs/sockjs-protocol and thus there are SockJS server implementations for any language you pick. Finally, SockJS does work behind loadbalancers.
So although the general functionality in Socket.io and SockJS is quite similar, the focus of the projects is different.
Majke, does SockJS do reconnects and heartbeats? I really appreciate the client automatically reconnecting to the server after a server restart. With that said, I agree with your sentiments on Socket.IO's API. It's also worth noting that Socket.IO has some serious stability issues (read the 161 issues on Github)that would make me consider using SockJS.
No. WebSocket API doesn't do automatic reconnects. Also, it is impossible to get have it built-in: every single application will need to behave differently after reconnection! For example - you may want to make sure that your web app synchronised state after the reconnection (and that's very application specific thing).
So, as with WebSockets, reconnecting is your responsibility. You're free to implement exponential backoff or any other thing you want. Frankly - that's quite simple.
> does SockJS do heartbeats?
SockJS server is expected to send simple frames once in a while to make sure that load balancer won't kill the long-polling connection. But this is not exposed to the user.
Again, WebSocket API does not expose heartbeats AFAIK. And once again, implementing that on the application layer is not terribly complex and allows you to have behaviour that perfectly suits your needs.
Once I implemented it I realised that Chrome and the iPhone browser use different versions of the WebSockets protocol, so it was impossible to debug in the browser. Sounds like SockJS might help with that.