Which websocket library to use with Node.js?

The Question :

437 people think this question is useful

Currently there is a plethora of websocket libraries for node.js, the most popular seem to be:

However I can’t find any solid concrete comparisons between any of them… Apparently Socket.io was awesome, but has become quite dated and has failing builds. Both ws and websocket-node claim they are the fastest. And engine.io seems new, but a lot heavier than the lighter aletarntives.

It would be amazing if we or someone could put together an answer that serves as a guide on which socket library to use and when, as well as a comparison between them.

The Question Comments :
  • If this gets closed, where should a question like this go? As the answer will be incredibly useful… Seems unfortunate that such a prominent question shouldn’t reside here.
  • Woot woot for community wikis, meaning that despite the question being closed from new answers, we can still improve the community wiki answer below 🙂
  • I agree, I would like to see this kind of question not just allowed, but encouraged. OK, they may not be relevant in a years time, but till then they will save the world.
  • @balupton can you update the community with your choice and if you are happy with it? is it socket.io?
  • @Cgraphics I use Primus with ws these days, as ws is all I needed, if I need something more extreme, I just swap out the undering library and keep the same api thanks to Primus. Works wonders.

The Answer 1

396 people think this answer is useful

Getting the ball rolling with this community wiki answer. Feel free to edit me with your improvements.

  • ws WebSocket server and client for node.js. One of the fastest libraries if not the fastest one.

  • websocket-node WebSocket server and client for node.js

  • websocket-driver-node WebSocket server and client protocol parser node.js – used in faye-websocket-node

  • faye-websocket-node WebSocket server and client for node.js – used in faye and sockjs

  • socket.io WebSocket server and client for node.js + client for browsers + (v0 has newest to oldest fallbacks, v1 of Socket.io uses engine.io) + channels – used in stack.io. Client library tries to reconnect upon disconnection.

  • sockjs WebSocket server and client for node.js and others + client for browsers + newest to oldest fallbacks

  • faye WebSocket server and client for node.js and others + client for browsers + fallbacks + support for other server-side languages

  • deepstream.io clusterable realtime server that handles WebSockets & TCP connections and provides data-sync, pub/sub and request/response

  • socketcluster WebSocket server cluster which makes use of all CPU cores on your machine. For example, if you were to use an xlarge Amazon EC2 instance with 32 cores, you would be able to handle almost 32 times the traffic on a single instance.

  • primus Provides a common API for most of the libraries above for easy switching + stability improvements for all of them.

When to use:

  • use the basic WebSocket servers when you want to use the native WebSocket implementations on the clientside, beware of the browser incompatabilities

  • use the fallback libraries when you care about browser fallbacks

  • use the full featured libraries when you care about channels

  • use primus when you have no idea about what to use, are not in the mood for rewriting your application when you need to switch frameworks because of changing project requirements or need additional connection stability.

Where to test:

Firecamp is a GUI testing environment for SocketIO, WS and all major real-time technology. Debug the real-time events while you’re developing it.

The Answer 2

40 people think this answer is useful

Update: This answer is outdated as newer versions of libraries mentioned are released since then.

Socket.IO v0.9 is outdated and a bit buggy, and Engine.IO is the interim successor. Socket.IO v1.0 (which will be released soon) will use Engine.IO and be much better than v0.9. I’d recommend you to use Engine.IO until Socket.IO v1.0 is released.

“ws” does not support fallback, so if the client browser does not support websockets, it won’t work, unlike Socket.IO and Engine.IO which uses long-polling etc if websockets are not available. However, “ws” seems like the fastest library at the moment.

See my article comparing Socket.IO, Engine.IO and Primus: https://medium.com/p/b63bfca0539

The Answer 3

32 people think this answer is useful

npm ws was the answer for me. I found it less intrusive and more straight forward. With it was also trivial to mix websockets with rest services. Shared simple code on this post.

var WebSocketServer = require("ws").Server;
var http = require("http");
var express = require("express");
var port = process.env.PORT || 5000;

var app = express();
    app.use(express.static(__dirname+ "/../"));
    app.get('/someGetRequest', function(req, res, next) {
       console.log('receiving get request');
    app.post('/somePostRequest', function(req, res, next) {
       console.log('receiving post request');
    app.listen(80); //port 80 need to run as root

    console.log("app listening on %d ", 80);

var server = http.createServer(app);

console.log("http server listening on %d", port);

var userId;
var wss = new WebSocketServer({server: server});
    wss.on("connection", function (ws) {

    console.info("websocket connection open");

    var timestamp = new Date().getTime();
    userId = timestamp;

    ws.send(JSON.stringify({msgType:"onOpenConnection", msg:{connectionId:timestamp}}));

    ws.on("message", function (data, flags) {
        console.log("websocket received a message");
        var clientMsg = data;



    ws.on("close", function () {
        console.log("websocket connection close");
console.log("websocket server created");

Add a Comment