When building a real-time application, there’s a moment where you have to choose how to implement the realtime data exchange between client and server.
WebSockets and Socket.IO are probably two of the most popular solutions for implementing real-time communications in the modern web.
But which one should we choose? What are the differences between these two technologies?
Let’s find out!


When talking about WebSockets, we’re referring to a web communication protocol that provides a full-duplex communication channel over a single TCP connection.
In few words, it allows interactions between client and server with a minimum overhead, allowing us to build applications that uses the advantages of real-time communications.

For instance, imagine if you’re building a chat application: you need to receive and send data as soon as possibile, right?
Well, that’s the right job for WebSockets! You can just open one TCP connection and share data leaving it open as long as you need it.

WebSockets first appeared in 2010 in Google Chrome 4, and the first RFC (RFC 6455) has been published one year later, in 2011.

Great use cases for WebSockets includes:

  • Chat Applications
  • Multiplayer Games
  • Collaborative Editing
  • Social Feeds
  • Location-based Applications

and many more.


Socket.IO is a JavaScript library built on top of WebSocket... and other technologies.
In fact, it uses WebSockets when available, but it’s ready to fallback to other technologies such as Flash Socket, AJAX Long Polling, AJAX Multipart Stream and many more; that allows Socket.IO to be used in contexts where WebSockets are not supported (example: legacy browsers).

Differences between WebSocket and Socket.IO

The main advantages of Socket.IO over WebSockets are:

  • Unlike WebSocket, Socket.IO allows you to broadcast a message to all the connected clients. For instance, if you’re writing a chat application and you want to notify all the connected clients that a new user has joined the chat, you can easily broadcast that message in one shot to everyone.
    Using plain WebSocket, you’ll need a list of all the connected clients and then send the message directly one by one.
  • Proxies and load balancers makes WebSockets hard to implement and scale. Socket.IO supports these technologies out of the box.
  • As said before, Socket.IO is able to fallback to technologies other than WebSockets when the client doesn’t support it.
  • If (for some reason) a WebSocket connection drops, it will not automatically reconnect... but guess what? Socket.IO handles that for you!
  • Socket.IO APIs are built to be easier to work with.

So, it seems that Socket.IO is something like “the heaven of real-time communications”, right?
Well, there are actually some good reasons for using vanilla WebSockets!

First of all, every modern browser supports WebSockets these days.
Socket.IO uses much more boilerplate code and resources in order to make it fallback to other technologies. Most of the time, you don’t need this level of support!
Even in terms of network traffic, Socket.IO is way more expensive.
In fact, with plain WebSockets the browser may need to run just two requests:

  1. The GET request for the HTML page
  2. The UPGRADE connection to WebSocket

and that’s it. You’re ready to start a realtime communication with your server!
But what about Socket.IO?

  1. The GET request of the HTML page
  2. Socket.IO client library (207kb)
  3. Three long polling Ajax request
  4. The UPGRADE connection to WebSocket

in a world where we’re using a lot of JavaScript code and libraries are drastically reducing their weight... 207kb are a lot! And what about all these requests? What a waste of network traffic!

There’s even an npm package called websocket-vs-socket.io (see here) that has been built for comparing the network traffic of those two technologies:

WebSocket network traffic:

Socket.IO network traffic:

what a huge difference!

So, what should I choose?

Well, there’s not a simple answer to this question.
Socket.IO may make things a bit easier for sure; you don’t have to worry about load balancer related issues, connection failures and message broadcasting... but are you sure you really need these features? Just the Socket.IO client library alone is heavier than React, Redux and React-Redux packaged together. Are you sure that you can’t use the browser native WebSocket API?

Another thing to keep in mind is that Socket.IO, implemented server-side, is a custom library/framework where most of the time you’re not following the vanilla WebSocket logic, because of the abstractions applied by Socket.IO itself.
If you’re refactoring your Node.js microservices (let’s say) to Go, Elixir, Java or any other language, you’ll have to rewrite most of the logic behind the Socket.IO behavior in order to achieve the same results with vanilla WebSockets. For instance, think about broadcasting a message to every connected client: with Socket.IO is just one method (.broadcast), but in vanilla WebSockets you’ll have to implement it on your own, so you’ll have to rethink about the way it works.
So maybe, it is worth it to start to work with vanilla WebSockets from the beginning, so it will be easier to refactor, extend or implement new features in other languages (if you’re writing microservices/lambdas etc).

So, what will you choose for your next real-time application?

Article written for Ably

Did you like this article? Consider becoming a Patron!

This article is CC0 1.0 (Public Domain) licensed.