1

I have some experience with socket.io and the main reason I was using it previously is to have a fallback in older browsers. Currently I have to develop an app with websockets, which has specific browser requirements. When I checked the browser matrix for websocket support, I see that all the browsers I need support websockets.

So right now I have a dilemma. Should I stick with socket.io or implement it with pure websockets? When I checked websocket API, I see that it is super simple. I made a small research into this problem and also this question sounds similar, it's main component is compatibility with old browsers (which I do not care).

So is there any advantage of socket.io if compatibility is not an issue?

Community
  • 1
  • 1
Salvador Dali
  • 214,103
  • 147
  • 703
  • 753
  • Honestly I'm starting to think that socket.io and SockJS are mostly unnecessary today. First: browsers that don't support websockets are quickly fading. Second: reconnection, broadcasting, etc., are easy to implement. The last point is that "web socket traffic can get blocked by firewalls and proxies" and I'm really wanting to understand this point more clearly. So far I've read a bunch of articles and none are convincing; they brush over the issue and make the assumption that this somehow must be the case, but no clear evidence or explanation is given. – Marius Jul 25 '15 at 20:40
  • @Marius socket.io is just a wrapper that makes your life easier. of course you can implement all its features yourself, but why? :) it already has been done for you. by the way, recently [socket.io started to support peer-to-peer connection](http://socket.io/blog/socket-io-p2p/) via WebRTC (though i didn't try it, yet) – Oleg Jul 26 '15 at 13:42
  • @Curious I'm wondering if socket.io's features are necessary. I would prefer to not use it if I don't need it. It sounds to me like pure websockets should work everywhere today. (There is some concern that they don't work with some proxies, but that is for non-browser clients that are not proxy-aware: [here](http://stackoverflow.com/questions/2201317/why-dont-current-websocket-client-implementations-support-proxies/2291377#2291377) ) – Marius Jul 26 '15 at 17:36
  • Just a thought for one use-case: If your transferring binary data, direct access using the Websocket API is superior, as you can avoid the Base64 encoding that will bloat the data transferred. Also, Socket.io is a wonderful wrapper, but it's also filled with stuff you don't need if you don't need a fallback... so you can enjoy a lighter codebase. – Myst Jul 27 '15 at 02:09

1 Answers1

1

Yes, there are. I can see 3 advantages of using Socket.IO even when developing for new browsers:

First of all, there are firewalls (see comments below), antiviruses, and proxies that block WebSockets. In this case XHR fallback would be extremely useful to ensure your service's availability for all users.

Second, Socket.IO supports autoreconnection, so you don't have to worry about temporary network failures.

And third, there are rooms and namespaces support, which makes writing real-time applications much easier and enjoyable.

Oleg
  • 22,300
  • 9
  • 68
  • 84
  • 2
    Hi @Curious, is the first point really true? I wonder how a firewall would block websockets. Are you talking about port blocking? Or are you talking about the possibility of semantic blocking, a firewall opening packets and disallowing WS packets? In my thinking, it would have to be the latter (explicit semantic blocking) because you can (and probably should) use websockets on HTTP ports (80, 443). – Marius Jul 25 '15 at 20:31
  • @Marius it looks like you are right. I've just googled about this question and came to the understanding that there are no specific rules to block websockets, since they use the same ports as main app do (as you mentioned). [Here is](http://stackoverflow.com/questions/1967943/will-html5-websockets-be-crippled-by-firewalls) one of the resources that shed light on this. Good point Marius! – Oleg Jul 26 '15 at 13:33