This is interesting when you want near realtime performances, as you don't have all the culprint of a http request : you basically just send a few octets (a json document, or even just a simple value), and you don't have to build a request and negotiate a connection.
This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building headers, encoding body, etc) [1]. A socket (be it a websocket or a classic socket) has this advantage that all the negotiating part is already done and you just have to send the message, in whatever format you want. Decoding the request on server side is way easier too.
clients don't have any api to get at data pushed by http/2 - it is not a websocket replacement and can't be used for the same things. http/2 will be used to multiplex static resources to clients - not application data
I've been out of front-line web development for a while. Are Websockets supported widely enough that a developer can reasonably assume they are available and not have to worry about workarounds such as comet/long polling?
Yes, I would say they're an expected browser feature these days, with over 94% global browser availability [0] (basically anything >= IE10).
The cool thing about Phoenix specifically is that they provide a JS client to integrate with a Phoenix Channels [1] backend that will automatically fail-over to long-polling if window.WebSocket is not available [2]. These Phoenix Channels are set up to be transport agnostic, so you don't have to write any special backend or client code to handle one way or the other, it "just works" for the most part.
The last time I did anything with Websockets was about 5 years ago and they were relatively well supported by browsers even then. I used socket.io because it automatically falls back to long polling when native Websockets are not supported. I am guessing if you needed 100% support this may still be a good option.
[EDIT] I see another commenter in this thread mentions phoenix.js beating socket.io. Thanks, I will have to look into this!
Please anyone correct me if I'm wrong, but there's no raw socket interface in browsers, as far as I know. Websockets are the closest thing, while still ensuring usual client side security (like preventing cross site request).
This is not something obvious because we have helpers to make http requests, but there are many things going on while issuing a http request (building headers, encoding body, etc) [1]. A socket (be it a websocket or a classic socket) has this advantage that all the negotiating part is already done and you just have to send the message, in whatever format you want. Decoding the request on server side is way easier too.
[1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Me...