The applications for sockets are endless. It solved a lot of problems that developers have had for ages. Web sockets allowed us to persist connections to servers and exchange messages without needing to rely on bulky HTTP requests on every request. This basically applies to both web sockets and socket.io. So what's the difference? Is there any? And which is better for you?

Similarities

Let's start by talking about the similarities. In short, socket.io is a wrapper around web sockets. In fact, you literally choose between long polling and web sockets as a transport when creating a socket.io server.

But you need to be considerate since socket.io states in its documentation that you should not try to connect to a socket.io server with a web sockets library because socket.io adds a lot of intermediate layers which makes them sort of incompatible (another way of saying really hard/time consuming to re-implement)

Differences

How about differences? Well, when using socket.io you can send named messages. Although in web sockets you can imitate that behavior by always sending an object with a type and data attributes where the type is the message name and the fata being the data that needs to be sent. It's just easier to simply name the message in socket.io and you don't need to have a large switch statement in your on message event in web sockets. Another core difference is that socket.io supports long polling. This means that the connection will try to send the data in the form of a normal HTTP request instead of opening a web socket connection. Why is this important you may ask? Well, it's because some old browsers may not be compatible with web sockets.

What socket.io does is that it asks you to order the transports long polling and web sockets) in the order you prefer. By default it has long polling first followed by web sockets. This means (using default configuration) that socket.io will connect using long polling and then try to upgrade to web sockets which is basically the better option but it starts with the option that is for sure will work on all devices (long polling). This way if you use socket.io, you are sure that the implementation will work regardless of the client's ability to handle web sockets or not. On the other hand, if you're using web sockets, you will have to check if the client is compatible with it or not. You can try and configure socket.io for a different behavior as you see fit of course like for example force it to use only web sockets or only long polling for example.

Some great socket.io features

One other thing that socket.io does better than web sockets is that it provides the user to implement a callback which allows the server to reply to a certain message like it's a HTTP request, but at the same time it isn't HTTP.

Another really awesome feature is the ability to attach things to a socket.io connection like a cookie or an auth header which allows users to implement many features like auth for example with ease instead of relying on complex architectural decisions.

The downside of socket.io

A problem that might be the deciding factor for you when choosing socket.io is the libraries available. Socket.io itself lists libraries for around 7 major programming languages but you might be using something different. At this point, you might need to rely on community maintained implementations of socket.io and you might be forced into using an older version of socket.io because the library hasn't been updated. On the other hand, web sockets is basically built into programming languages since it's a standard protocol.

In a nutshell

We, at entracked.com, believe that socket.io is the simpler, more versatile solution. It provides great features with a lot less complexity than web sockets does. And since entracked aims to create the simplest experience, we decided to go with socket.io in our own system.

What do you think? Do you agree with our decision? Which one do you use for your projects? Let us know in the comments below.

By Omar Waleed, Founder of Entracked