I don't know, socket.io already feels like an unnecessary abstraction to me, and this is another abstraction on top of it. I generally dislike APIs that hide what's happening under "magic" abstractions, plus this seems leaky, as it abstracts on socket.io but requires you to know how it works.
Although WebSockets are simple to use, there are a bunch of issues that the spec doesn't cater for when using them:
1. Connectivity. The WebSocket connection is only as persistent as the underlying network connection between the client and the server. A person playing a web-based game on a mobile device on a train that then goes under a tunnel is a good example.
WebSockets do not reconnect if they close unexpectedly. In such cases, you have to throw the WebSocket instance away and create a new one, and so you end up having to implement your own reconnectivity logic.
2. Message Sending. Messages will only be sent if the connection is open. If it is closed, not only do the messages not get sent, but they don't get queued up either, so they end up disappearing into the ether.
If you want to guarantee message sending, then you end up having to implement a queuing mechanism that is linked to knowing the status of the WebSocket connection, and is able to send when the conditions are right.
3. If you don't use WSS (WebSocket Secure Server) for the WebSocket host and connection url, then the WebSocket connections can get interfered with if they are connecting over a mobile network - ISPs sometimes inject packets which ends up distorting WebSocket connections over http. But I think since the days of Ed Snowden's leaks everyone has their production WebSocket systems setup using WSS.
This comes from the experience many years ago of working on a WebSocket-powered web framework called SocketStream which ran into these issues, and then some years ago I managed to build a library that focussed on dealing with those WebSocket-related issues, called Sarus: https://github.com/anephenix/sarus
WebSockets is great though, and there is still much that can be done with it as this library in the HN post demonstrates.
I have to admit I've never tried to use web sockets without socket.io. Are they really as simple as you claim?
Same here. I guess we'll just have to try
It doesn't look difficult at all now I look at it https://javascript.info/websocket
socket.io has a lot of optimizations that can help scale message broadcast to many connected users, and also handles things like client disconnections, delivery confirmation, etc.
It is not unnecessary, and you probably could build something that does the same things in a day or two, but I'd be surprised if it was something that scales as well to >100,000 simultaneously connected people
> socket.io is probably one of the most unnecessary libraries on this planet. Websockets are already as simple as possible.
Eh... While I agree that socket.io is one of those libraries you could probably "write" in an afternoon, and Websockets are simple, there are a couple of things that are kinda painful to rewrite time after time:
- keepalives to detect dead sockets
- reconnection logic with backoff
- ability to switch to long-polling for weird environments
- basic multiplexing/namespacingWebsockets already have keepalives. Everything but long polling is doable in a few hours and can probably be one-shotted by an LLM. For long-polling, you can just drop down to Fetch calls.
This is true. Just a few days ago I had Claude one-shot some WebSocket utilities for reconnect and message queueing. It took 2 minutes.
I've written countless WebSocket wrappers in the past (similar aversion to socket.io as others in this thread). The one-shot output was perfect. Certainly better than my patience would've allowed.
Maybe socket.io is doing something fancy on the server side, but for clients, it's absolutely overkill.
socket.io is probably one of the most unnecessary libraries on this planet. Websockets are already as simple as possible.
In fact, websockets work so well I use them as a generic TCP replacement, because the message oriented transport model gives me 99% of what I need with the exception of custom message types. Leaving that out was a massive letdown to me, because you now need to carry a way to identify the message type inside the body, rather than just throwing the message itself into the appropriate protocol parser (e.g. a schema based binary format).