Comment by leggetter | Hacker News Reader

Comment by leggetter | Hacker News Reader

Parent Full thread

SockJS is definitely a reasonable choice as a base. At Pusher we use a fork of SockJS for HTTP fallback but we actually use em-websocket [1] (ruby) for our WebSocket API. Given the opportunity we'd probably move away from SockJS to something much simpler because we only want the HTTP fallback part and it only handles < 8% of our connections.

If you _only_ want WebSocket connections with no HTTP fallback then Faye WebSocket [2] may be an option. But any production application is going to require fallback for older browsers and pesky proxies/firewalls.

Faye [3] is solid (obviously used Faye WebSocket), has implementations in Node and Ruby, but is a PubSub solution. I'd kinda argue that any real-time app needs at least PubSub functionality anyway.

The ws Node module [4] is apparently "The fastest RFC-6455 WebSocket implementation for Node.js" and receives contributions from 3rd-Eden who is also behind Primus [5]. But it's also WebSocket with no fallback.

I haven't used Primus, but I really like the idea of offering a layer above the underlying connection engine. I've seen contributions to Socket.IO dip in the past (prior to CloudUp being acquired by Automattic), but Socket.IO is used by so many apps that somebody is always likely to maintain it for the foreseeable future. I'm generally in favour of adding abstractions around layers like this (connectivity, DBs, Message Queues, Hosted Services etc.). However, in this case you're then adding a dependency on Primus. Isn't software fun!

[1] https://github.com/igrigorik/em-websocket [2] https://github.com/faye/faye-websocket-node [3] http://faye.jcoglan.com/ [4] https://github.com/websockets/ws [5] https://github.com/primus/primus

We're lucky in that we require web workers, so we get web sockets compliance for free. We also are an infrastructure deployment, so we get some leeway in ignoring shitty devices.

I made the decision early on to push on the business side as hard as possible to only use modern web tech, and it has saved us a lot of trouble. HTML5, without compromise, is nice.

Lucky indeed! I've been pushing for us to drop IE7 (and maybe 8) so we can move to more modern tooling and libraries as part of the development process. But customer requirements mean we've got to stick to IE7 for now.

EDIT: But this is an important factor for dev in general http://www.w3.org/TR/html-design-principles/#priority-of-con...

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.

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