SSE is just a long-running connection, so it fits with HTTP/2 pretty well (and HTTP/1 for that matter).

H2 push needs to be linked to an initial response, and I don't think it's acceptable to push resources once the initial response is complete. Also, H2 push is pretty much a request/response pair, so it can be cached, so it doesn't really fit the SSE model.

You're right about websockets though. At some point they'll be replaced with something more H2-like, but it won't be push-based.

If the next protocol iteration is something like QUIC, then the WS could just be implemented over QUIC UDP packets.

Right; Server Push isn't "send the client arbitrary data"; Server Push is "move link/subresource prefetch logic to the server, where you can take advantage of optimizations like single JOIN-queries that give you all you need to output multiple resources, actually outputting multiple responses."

SSE is not extremely HTTP-y but it at the core is the sort of thing we have used for ages for the same thing we use web sockets. The only difference between SSE and old good polling is the presence of a nice API on the browser side.

We have worked with SSE, HTTP/2 and HTTP/2 Push of SSE event streams and it is a combination made in heaven. In particular, we use SSE events to have the server announce to the browser when a particular segment of an interlaced or progressive image has been delivered. With this combo, the SSE events can be delivered on the wire very close to the data frames for the image pieces themselves.

> HTTP/2 Push of SSE event streams

That's... brilliant, actually! It's like making a request in Go, and being returned a response promise, along with an "events that occurred during response processing" channel, which you can select() on until the promise is resolved.

Confusing name but different use cases. HTTP/2 does introduce efficiency gains that will benefit SSE, but it's unlikely to supplant WebSockets entirely.

https://www.infoq.com/articles/websocket-and-http2-coexist

Server push sends responses to requests, only these requests are “promised” by the server. So, for every event pushed, the server would have to send at least three frames: promise (the synthesized request), response headers, and response data.

Also, you would still need something else for HTTP/1.x. Even an HTTP/2 client does not have to support server push, and can even ask the server to disable it.

Why do you think server-sent events are not HTTP-y? I found them as elegant as modern Web technology gets.

WebSockets aren't perfect but they're a lightweight full-duplex protocol that is great for many real-time scenarios. Not being the same as HTTP is the point.

Why would you do away with them just because they aren't HTTP-y?

The fetch API is probably the closest to what you're asking for, as it allows for streaming a response, but is basically a plain HTTP request.

FWIW there is an old spec draft for WebSockets over HTTP/2: https://tools.ietf.org/html/draft-hirano-httpbis-websocket-o...

See the related curl blog post 'No websockets over HTTP/2' [1], which talks about that spec and how it didn't generate enough interest from concerned parties, and goes into some alternatives and perspectives on the matter.

[1] https://daniel.haxx.se/blog/2016/06/15/no-websockets-over-ht...

Good post.

> Sticking to HTTP/2 pretty much allows you to go back and use the long-polling tricks of the past before websockets was created.

Interesting how things turned out. The old bad way is now a good way. Last time I've checked Google Hangouts also used polling instead of WebSockets.