Hacker News Reader

Comment by oelmekki | Hacker News Reader

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.

[1] https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Me...

View on HN

HTTP/2 multiplexes requests over one socket connection, so it should solve most of problems you state.

Except browsers do not allow Push on http/2 so far

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.

[0] https://caniuse.com/#search=Websockets

[1] https://hexdocs.pm/phoenix/channels.html

[2] https://github.com/phoenixframework/phoenix/blob/master/asse...

Almost, depending on who you ask.

But Phoenix contains these workarounds and it works great. So with Phoenix Channels you can really just act like It Just Works.

(phoenix.js is one of the best parts of the library IMHO - its design beats eg socket.io dead out of the water)

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!

> This is interesting when you want near realtime performances, as you don't have all the culprint of a http request

Excellent. How about raw TCP then?

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 correct. Its not far off from a normal http request, the performance savings is primarily in the TCP/SSL handshaking that goes on.

Reply on news.ycombinator.com