[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.