[RFC] Lite javascript client

[darrachequesne]

Hi everyone!

Do you think it would make sense to provide a WebSocket-only client?

Pro:

• this could greatly reduce the bundle size

Current composition of the size of the bundle (10.6 kB min+gzip) :

engine.io-client: 46% (this would go ⬇️)
socket.io-client: 27%
socket.io-parser: 13%
engine.io-parser: 9% (this would go ⬇️)

Source: https://bundlephobia.com/package/[email protected]

• some users are already using

import { io } from "socket.io-client";

const socket = io({
  transports: ["websocket"]
});

so they could directly use the new implementation.

Cons:

• no more fallback to HTTP long-polling
• new code => new bugs

We could even go further and remove the multiplexing feature, implemented in the Manager class.

What do you think?

[qiulang]

@darrachequesne hi I was about to ask a similar question before knowing you have such plan (Yes, Please!)

So how do I compile the client code with WebSocket-only. I saw someone updated webpack.config.js, adding such rule.

module: {
   rules: [{
     test: /engine.io-client\/lib\/socket.js$/,
     loader: 'string-replace-loader',
     options: {
       multiple: [{
         search: '["polling", "websocket"]',
         replace: '["websocket"]',
       }, {
         search: "['polling', 'websocket']",
         replace: "['websocket']",
       }]
     }
   }

It seems to work but I have doubt that such a simple replace would make the whole client codes work.

[qiulang]

@darrachequesne since no update for this issue for a while, I would like to know do you plan to do this in the near future ? I am very much like to see it happen!

[misbahkhalilaz]

@darrachequesne I'm a fan of this library, and this would be really awesome. Do you have any updates on this?

[darrachequesne]

Hi! It's in our backlog, if there's enough interest we could implement it quickly I think.

[qiulang]

@darrachequesne I would like to point out that at least there has been a socket.io WebSocket-only client called https://github.com/weapp-socketio/weapp.socket.io for 3 years, which is kinda popular among Chinese developers because they use it for alipay and wechat mini program. I briefly check their implementation, for example check how they set their webpack.config

I think their implementation is problematic, e.g. they used what I pasted above to remove the polling and they use new webpack.NormalModuleReplacementPlugin(/debug/, process.cwd() + '/support/noop.js'), to remove debug library.

So I hope you can provide an "official" version.

[qiulang]

Not meant to push you, but a little incentive (lol)
When google the term socket.io and websocket together, the top hits, except for socket.io own site, are articles from Ably (we talked about Ably before) and I know this article Everything you need to know about Socket.IO is quite popular. When reading this article, these words would make an unfortunate impression ,

If you don’t need to support older browsers and aren’t worried about client environments which don’t support WebSockets you may not want the added overhead of Socket.IO. You can minimise this impact by specifying to only connect with WebSockets. This will change the initial connection to WebSocket, but remove any fallback.

In this scenario, the client will still need to download the 61.2 KB socket.io JavaScript file. This file is 61.2 KB. More information on this process is here.

Whoever is familiar with The Cost Of JavaScript maybe freak out with 61.2KB.

[darrachequesne]

OK, so I've implemented a WebSocket-only engine, which can be used instead of the one provided by the engine.io-client package.

This reduces the size of the minified bundle by about 33%. Something like:

• minified: 36 kB => 24 kB
• minified + gzipped: 11 kB => 8 kB

I'm wondering if we should publish as is, or remove some additional features to further reduce the size. @qiulang thoughts?

[qiulang]

@darrachequesne I just read your reply. Thanks for doing this. Let me try it next week (3.27) and get back to you.

[qiulang]

@darrachequesne I checked your sample code and even replaced socket.io-client with your sample code in one of my projects to see if I can make it work. And with some modification in function decode(data) I did!

I think what you provide in your sample code and the guid are already the minimum features. After all, we have to differentiate WebSocket browsers provide from socket.io-client. As a matter of fact I think maybe you can add Acknowledgements callback back, that will be another differentiating factor. So how many KB is needed for Acknowledgements?

[darrachequesne]

@qiulang you are right, the client described in the guide is the absolute bare minimum, its bundle size is ~1kB (you can run the check-bundle-size.js script in the repository).

I think the following features are missing:

• acknowledgements
• authentication payload
• binary payloads
• catch-all listeners
• retries
• connection state recovery

[qiulang]

But I used your sample and find retried work.So were we talking about the same feature here reconnections vs "retries" ?

[darrachequesne]

@qiulang retries are indeed different from reconnections. It was added last February in version 4.6.0. It allows the client to retry sending a packet upon failure.

Reference: https://socket.io/docs/v4/client-options/#retries

[xzilja]

Would such client also improve performance (cpu / memory wise) in addition to size reduction benefits?
Also, can something like this also be applied to full socket.io library on the server?

[darrachequesne]

That's a good question! I think the performance of the client is mainly related to the management of the WebSocket connection and the parsing of the messages, which the lite client will have to do anyway, so the benefits should be rather limited.

[Ionys320]

I'm currently investigating on the necessary to keep the HTTP pooling system. In our usecase, it would be abnormal that our users need it, so only having the websocket system should be worth.

[dominiczaq]

Hey, can I help anyhow with this change? Happy to help with pushing this forward 🙏