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:
and many more.
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).
The main advantages of Socket.IO over WebSockets are:
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:
GETrequest for the HTML page
UPGRADEconnection to WebSocket
and that’s it. You’re ready to start a realtime communication with your server!
But what about Socket.IO?
GETrequest of the HTML page
UPGRADEconnection to WebSocket
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!
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!