Does not even back off. I like the idea of offering libraries that provide some abstraction over standard libraries, but what's the use if it's just the most trivial solution that's unusable for any production situation?
Author here: That's a good feature request. I shall implement a truncating exponential backoff algorithm tonight (maybe tomorrow).
I've been using this in production for over 2 years and my load levels have not caused any usability issues (even without backoff). But no doubt for heavier sites, this will be an excellent feature, so thanks for suggesting it. If you have other feature requests, please add them to the issue tracker as I'm more likely to notice them: https://github.com/joewalnes/reconnecting-websocket/issues
In answer to your question - the use of an abstraction is to allow new features (like the one you suggested) to be added in one place so individual users can easily make use of the additions.
I came to the comments to mention exactly this. A production solution needs to back off or you're going to DDOS yourself if your pubsub cluster falls over.
Always important because our beloved websockets are fragile!
socket.io has it built in, but in various projects I had to hoist my own reconnect functionality on top because reconnects kept failing.
engine.io aims to be more reliable than socket.io, mainly due to connecting via the fallback methods first, then establishing a websocket connection. I have not used e.io yet but intend to soon.
Socket.io used to be good, but it is littered with bugs and has been promising 1.0 for nearly 2 years without a single update. We switched to SockJS a few months ago and haven't looked back.
Socket.IO is awesome, but my understanding is that Socket.IO also requires server side components as it adds a layered protocol on top of the WebSocket transport.
Are you referring to the ping/pong message frames in the WebSocket transport protocol, or just a general heartbeating protocol layered on top of WebSockets?
If it's the former, then there's nothing ReconnectingWebSocket can do here as this is not exposed by through the standard JavaScript API. Even if it was exposed, I'm not entirely sure what it would do.
The latter requires a custom protocol built on top of the user's WebSocket messages. This would require additional code on the server to process the messages. Libraries would have to be created for the various server side WebSocket implementations. It's a much messier abstraction, and I'd prefer this library to stick to one thing and do it well.
> no mention of what happens to messages in
> transit when the connection drops
In this regard it behaves exactly like a regular WebSocket connection - the message is lost. All this library care of is ensuring that a new connection is opened.
> Are you referring to the ping/pong message frames in the WebSocket transport protocol, or just a general heartbeating protocol layered on top of WebSockets?
I'm talking about a protocol layered on top, for exactly the reason you state.
> In this regard it behaves exactly like a regular WebSocket connection - the message is lost.
But it doesn't, with a regular WebSocket connection, you know that if a subsequent message is received and responded to, all previous messages were also received.
> It's a much messier abstraction, and I'd prefer this library to stick to one thing and do it well.
It doesn't and can't. What you've created is completely trivial. If it was indeed better, it would be the behaviour of WebSockets by default.
