Why you should never use Socket.IO

I like the library but the title is pure clickbait. I expected an article arguing this position, not a github repo. The github repo simply does not explain why &quot;you should never use Socket.IO&quot; - performance is not necessarily the only feature Socket.IO offers, it could be API surface, etc..Socket.IO is also two parts - a client and a server, and this library is just a server.<p>The title is doubly worse because it doesn&#x27;t actually promote the library. You could quote the repo instead - &quot;mWebSockets - a lightweight, efficient &amp; scalable WebSocket server&quot;

I appreciate there&#x27;s a drop-in replacement line for existing socket.IO apps. Thanks for making something awesome

The killer Socket.IO feature for me is being able to talk to clients from other server processes using socket.io-redis and socket.io-emitter [1].<p>Any ideas how we can achieve something similar using µWS? I guess using it as the engine in Socket.IO would do it, but let’s assume we want to get rid of Socket.IO entirely.<p>[1] <a href="http:&#x2F;&#x2F;socket.io&#x2F;docs&#x2F;rooms-and-namespaces&#x2F;#sending-messages-from-the-outside-world" rel="nofollow">http:&#x2F;&#x2F;socket.io&#x2F;docs&#x2F;rooms-and-namespaces&#x2F;#sending-messages...</a>

Can I have opinions from someone who have already used this?

Hard to take a &quot;socket.io killer&quot; seriously when it doesn&#x27;t even implement bare necessities like message_id callbacks:<p><pre><code> socket.emit(&#x27;msg&#x27;, &#x27;hello&#x27;, (err) =&gt; ...) </code></pre> At which point the nice part of using socket.io is that there are a variety of clients (and server impls) so every one of your users doesn&#x27;t need to implement things like message_id callbacks.

Care to share why Socket.IO is so poorly implemented? It seems to be a small wrapper around the socket protocol—what could be written so poorly?

Good post, but will sadly go unseen due to elections. Will try to share it once things calm down!