[bonobo]

I never took the time to try WebSockets, so please forgive me if this question doesn't make sense, but, does HTTP/2 supersedes WebSockets? I'm under the impression that HTTP/2 covers all the WebSockets' use cases, is this a correct observation?

[derefr]

There's not much you can do with a websocket that you can't do with a Server Sent Event stream plus AJAX requests. HTTP/2 just makes that design (relatively) performant by shoving all those together into one multiplexed connection.

Websockets are still important if you need something like real-time input-event streaming (e.g. for an online game); a properly-structured binary protocol sent over a websocket will be much lower-overhead than the equivalent HTTP/2 frames.

[jkarneges]

If you use WebSockets mainly because you want to multiplex many requests/responses over a single TCP channel, then HTTP/2 may be a preferable substitute for WebSockets.

If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative (though I've not heard of anyone actually doing this yet).

If you use WebSockets because you actually want a bidirectional message-oriented transport protocol, well then you'll keep using WebSockets. :)

[shorbaji]

> If you use WebSockets for "realtime push", then HTTP/2's server push feature could potentially be used as an alternative.

One thing to keep in mind with HTTP/2 server push is that a server can only send a push in response to a client request. So this isn't a drop-in "real-time push" mechanism. To implement the equivalent of real-time push would likely require client/server to keep a stream within the connection in the "open" state whereby the server can send continue to send data frames on that.

[bonobo]

    One thing to keep in mind with HTTP/2 server push is that a server can only
    send a push in response to a client request.

This was the difference that I was not aware of, thanks. So HTTP/2 server push is just opportunistic, while WebSockets are real-time push with a persistent connection.

[vladaionescu]

From what I could find online, there are no plans to include websockets as part of HTTP/2 (according to this: https://webtide.com/http2-last-call/ ). HTTP/2 is meant to supersede all websocket use cases.

[jkarneges]

Hmm, do the HTTP/2 authors say that it supersedes WebSockets? The article you linked to says that there may have been a missed opportunity regarding consolidation of framing protocols, but that alone doesn't imply that WebSockets are obsolete. I'd assume HTTP and WebSockets would continue to exist as separate protocols, as they always have.

[vbezhenar]

HTTP/2 does not allow communication from server to client. Server push is another matter, not really controlled by server or client. So you'll end up to polling server. This might be a bit more effective than HTTP/1 polling, but websockets will be better.

[Lukasa]

Sure it does. HTTP/2 streams are bidirectional. The websocket flow can be perfectly emulated in HTTP/2: make a websockety request, get a 200 HTTP response, then both sides keep the stream open and send data through it.

[vbezhenar]

How is it different from HTTP/1 with keep-alive connection?

[johnny22]

basic server push can be implemented with Server Sent Events: https://developer.mozilla.org/en-US/docs/Server-sent_events/...

[gkop]

No, specifically when you want a full-duplex link, you will still use websockets.

[euyyn]

Why? You can have full-duplex streams in HTTP/2 too.

[wmf]

At the protocol level or at the JavaScript level?