Hacker News Reader

Comment by jkarneges | Hacker News Reader

What's great about SockJS is it's meant as a WebSocket polyfill and nothing more. It also has some semblance of a protocol definition. This makes it an ideal foundation to build upon if what you really want is WebSockets, but you need a bandage for old browsers.

Meteor notably uses SockJS as part of their DDP spec.

Also Pushpin includes a SockJS to native WebSocket translator.

View on HN

It does seem to be the most commonly used WebSocket polyfill around. We also use web-socket-js [1] for fallback. But Version 3.0 of pusher-js [2] will remove that.

One negative with SockJS has been the complexity of the fallback approach on the client (the browser). Especially when it's only for 8% of connections. A single simple cross-browser HTTP-based transport would remove the code complexity and reduce the file size.

[1] https://github.com/gimite/web-socket-js [2] https://github.com/pusher/pusher-js/tree/r3.0.0

The problem is that even if XHR is on a local domain and ensured to work, long-polling is still more intensive than, for example a persistant frame, because you have to re-establish a new connection after each message, even if you bundle messages to a one second window, it's still got the overhead of a new connection (and the latency involved therin) which is even longer if HTTP2/SPDY + SSL.

Of course, that may well be enough for some situations, for others, there's too many server-pushed messages to keep up with that model as well.

The overhead of long-polling isn't quite so bad in practice thanks to persistent HTTP connections, where an existing TCP connection is reused for future HTTP requests. Pretty much all browsers support this, and so a re-poll is usually 1 packet.

Of course, long-polling is still more overhead than a streaming connection.

Reply on news.ycombinator.com