Our journey from WebSockets to HTTP/2: A story of what we learned

Some remarks on that:

> What if I still want to use WebSockets? You can either hold your breath and wait for WebSockets support on HTTP/2 or just stick with them under HTTP/1.1.

There's not a need to have "Websockets on HTTP/2". Websockets through an HTTP/1.1 update work fine and will continue to work in the future. The thing is: Both websockets and HTTP/2 take control over the whole TCP connection after you switch to one of those protocols, so they are exclusive. But that's fine, if you use websockets on HTTP/1 you also use one TCP connection exclusively for that websocket connection, and other HTTP requests must utilize different connections. It might be possible to embed websocket frames in HTTP/2 streams, but it's not really worthwhile, since you get the HTTP/2 overhead (per-stream flow-control on top of TCP flow control) and not much of the benefit (sites typically have one websocket connection, not dozens or hundrets).

On SSE vs Websockets:

Both have some advantages and disadvantages: SSE is easy to use, works with the standard HTTP programming model (one request and a loooong streamed response) and can therefore also use HTTP-related infrastructure (proxies, load-balancers, etc.). However you might not be able to use subscriptions from lots of SSE sources, since they also need an individual TCP connection in HTTP/1, and browsers limit those. With HTTP/2 that's less of a problem, but some might want to support HTTP/1 for backward compatibility reasons. Also if you have multiple SSE endpoints you do not have ordering guarantees, since they are running fully independent on different TCP connections.

With websockets you are not restricted to HTTP semantics, it's just a bidirectional connection which supports and kind of semantics on top (including request-response models, arbitrary streaming from client to server and the other way around). And on top of that connection there's an ordering guarantee. Websockets also have a better support for binary data transmission compared to SSE, which only supports "lines of text" by default. Of course you can base64 encode everything, but e.g. encoding JSON as base64 just in order to send it as "messages" over SSE sounds not very sexy from a performance perspective.

All in all I would say one should prefer SSE for stateless systems where the main usecase in server->client notifications, and websockets for stateful systems where there is some stored state on the server for each connection.