3 ms·

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 no

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?

bombtrack 9y ago
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 https://caniuse.com/#search=Websockets [1] https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html [2] https://github.com/phoenixframework/phoenix/blob/master/assets/js/phoenix.js#L693 https://github.com/phoenixframework/phoenix/blob/master/asse...
skrebbel 9y ago
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)
jtms 9y ago
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!

bombtrack 9y ago

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 https://caniuse.com/#search=Websockets [1] https://hexdocs.pm/phoenix/channels.html https://hexdocs.pm/phoenix/channels.html [2] https://github.com/phoenixframework/phoenix/blob/master/assets/js/phoenix.js#L693 https://github.com/phoenixframework/phoenix/blob/master/asse...

skrebbel 9y ago

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)

jtms 9y ago

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!