Hacker News Reader

Comment by TazeTSchnitzel | Hacker News Reader

What is the point of using socket.io today? Three years ago WebSocket support wasn't universally available, so you needed XHR etc. as a fallback. But now it's 2015 and everything supports WebSocket. Why not just use them directly? They have a super simple API. (see: http://ajf.me/websocket - a page I made about them)

If you're worried about firewall/proxy traversal, use wss:// (WebSocket over TLS), which not only traverses, but doesn't cause a speed and latency downgrade like falling back to XHR does.

I realise some sites might need to use socket.io if they're targeting legacy platforms, but that's an ever-shrinking slice of the market. For most sites it is probably overkill.

View on HN

Quoting myself the last time this question was asked (https://news.ycombinator.com/item?id=8917505):

On top of its transport layer abstraction, socket.io adds various useful features including events, rooms, namespacing, efficient/convenient (de)serialization of both JSON and binary data, and over-the-network callbacks. I've been using it in websockets-only mode for various projects (you can limit the transports used), because I don't care for slower / less reliable transports but still want the extra features.

EDIT: If you'll allow the plug, an MMO trivia game show I made using socket.io (and three.js): http://masterofthegrid.net/

Socket.io is wayyyyy more noob-friendly. If you send json over the wire, socket.io automatically converts it to a javascript object or array for you, ready to be used. The best feature however is that you can send emit any string as an event :

socket.emit("hello"); and the server can listen on this event with socket.on("hello"). If you want to do the same thing with the reference WebSocket you have to re-implement the same thing again and you will probably end up recoding the wrapper that socket.io already gives you.

This is trivial to do yourself. JSON.stringify(), JSON.parse(), switch() {}. It's not really some massive benefit of using the library. And this way there's no magic.

Also, magically trying to decode strings if they look like JSON sounds rather scary.

> Also, magically trying to decode strings if they look like JSON sounds rather scary.

That's not what's going on. Each message is tagged with a "type", and one of the tags means "JSON.parse this into an object" while another means "this is just a string".

The rest of the types are for control messages (like ping/pong), I believe.

> If you send json over the wire, socket.io automatically converts it to a javascript object or array for you, ready to be used.

That's literally 4 lines

    // sender
    ws.send({event: JSON.stringify(someObject));

    // receiver
    ws.on('message', function(str) {
       obj = JSON.parse(str);
    });

> socket.emit("hello"); and the server can listen on this event with socket.on("hello").

This is hardly any more lines of code

    // sender
    function sendEvent(eventName, data) {
      ws.send(JSON.stringify({event: eventName, data: data}));
    }

    // receiver
    ws.on('message', function(str) {
      var eventInfo = JSON.parse(str);
      eventEmittier.emit(eventInfo.event, eventInfo.data);
    });

Sure I'm glossing over a few things but EventEmitter is 10-20 lines depending on how crazy you want to get and wrapping both in a objects is probably another 10-20 lines

socket.io on the other hand is a C node.js plugin and 61000 lines of JS code :(

You don't even need an event emitter. In many cases you might just use switch(){}.

Socket.IO also gives you things like cross-everything callbacks:

     // server
     io.emit('event', function (msg) { console.log('Client responded!', msg) })

     // client
     io.on('event', function (cb) { cb('This is my response') })

And it also provides socket namespacing, and "rooms" (a bit like chat rooms), and broadcasts, and a bunch of things that I don't use.

Sure, you can bolt all of that on in probably a few hundred lines, but socket.io also doesn't just do sockets and events :)

(And it also does it in less than 61000 lines. You still need the "ws" module to do WebSocket stuff in Node, even if you don't use socket.io)

Socket.io also transparently handles sessioning and resuming of sessions (automatic reconnect), namespaces, filters, and a ton of other useful stuff for a moderately-complex application. If I'm just sending events between client and server (say, live-updating a common twitstream), regular ws is fine. But if I'm selecting and reflecting certain events to other connected clients by room, and don't want to worry about stuff like "oh hey, that guy needs to re-handshake because he lost network", socket.io provides a lot of useful sugar.

I don't normally like bashing open-source projects, but socket.io should not be used. It may be noob-friendly, but that's just because it does things so automatically that you can't really use it correctly. When I was a websockets noob, I used socket.io briefly, and it was a complete waste of time.

See, for example, https://github.com/Automattic/socket.io-client/issues/572 (closed without comment).

If you want a nice websockets library that handles old browsers, use SockJS. It's far better.

[edit: fixed a silly typo]

Agreed - I've been using SockJS for a while and haven't had any issues. It's got a super-simple API. (intended to be as close to the WebSocket API as possible)

If your language of choice has a SockJS implementation, I'd recommend it as a first option.

- Plenty of consumer grade firewalls and routers will mess up socket connections

- E-commerce sites can't afford to drop customers with old browsers (what's old anyway, a browser that is a few years old should be supported regardless)

- Some corporate networks won't support anything other than plain HTTP over port 80

And so on. 'Legacy' for you is everyday business for someone else.

IE 8 and 9 don't support web sockets. For many companies, that's still a significant piece of the market.

Thus the mention of "legacy platforms". If IE9 and below matters then, yes, you should use it.

I remember when Microsoft tried to pass IE9 as a "modern browser" - with less than half the HTML5 features of Chrome and Firefox at the time (which is still true for the latest IE versions btw).

IE11 is fairly modern. You can't berate Microsoft for trying to catch up.

We don't want to be in a position where there can't be new browser engines because they're not "modern" if they don't implement literally every feature their competitors support.

IE11 was fairly modern when it came out. It will likely be legacy long before IE12 or whatever they decide to call it comes out. They're not really going to be able to play keep up until they divorce the browser from the OS. Given that this is Microsoft it is kind of funny that this is their problem now.

> IE11 was fairly modern when it came out.

Still is. IE11 is an evergreen browser with constant improvement.

> It will likely be legacy long before IE12 or whatever they decide to call it comes out.

There won't be another IE. There will be Spartan.

> They're not really going to be able to play keep up until they divorce the browser from the OS.

They basically have, long ago. IE10 and IE11 aren't Windows 8-exclusive.

> IE11 is an evergreen browser with constant improvement.

Until Spartan comes out?

> There won't be another IE. There will be Spartan.

So we're going to be stuck supporting IE11 long after "Spartan" has taken hold just like every previous release? Doesn't that go against the whole purpose of the "Evergreen" browser?

> They basically have, long ago. IE10 and IE11 aren't Windows 8-exclusive.

I don't mean exclusive to the operating system. I mean that there are parts of the OS that rely on the browser libraries itself. And there are weird situations where OS things rely on IE libraries, or (Worse) Office Libraries. That at least for a while was one of the big reasons the problems would never get fixed.

Sorta wish they had shipped IE9 with Windows XP instead of Windows 7 so companies would have more incentive to drop IE9 support.

Those companies are part of the problem, not the solution.

FWIW, we're driving our users to deploy at least IE10 before talking to us, preferably IE11. Supporting old browsers is just not worth it--for devs in the short-term, or clients in the long-term.

Save them from themselves.

Supporting old browsers is just not worth it--for devs in the short-term, or clients in the long-term.

The part you missed is that it is worth it for clients in the short term. If you have an eCommerce site and a portion of your potential customers use IE8, then you cater to IE8. It's as simple as that. When your business depends on making money every month, "short term" or "long term" doesn't matter as much.

Countries still block websockets from other countries. We don't use pure websockets because AJAX polling still works even when firewalls and other hardware stop websockets.

Even over TLS? Are your connections being MITMed?

You shouldn't have any problems with firewalls so long as you use TLS. And if you don't use TLS and rely on XHR fallback, then you're suffering a downgrade in speed and latency.

We tried switching from SockJS to pure websockets and had to revert because it broke too many users, even though our website only supports WebGL (IE11, etc) and all communication is done over https/wss. One of the biggest problems was plugins like the zenmate privacy plugin https://chrome.google.com/webstore/detail/zenmate-security-p...

How do these plugins cause issues with WebSocket? Are they stripping SSL from connections? That makes me extremely suspicious of their authors. :/

> Even over TLS? Are your connections being MITMed?

Some corporate networks do MITM you and mandate HTTP only (we've seen this surprisingly often in the wild).

Now, for most apps this isn't a concern since those employees probably wouldn't be allowed to use the app, but it can be quite important for apps that specifically target large businesses.

Reply on news.ycombinator.com