Is this project still maintained? + discussion about the future of socket.io

[MickL]

I wonder if this project is still maintained. Last commit is 3 month ago and there are nearly 300 open issues.

It seems like socket.io is still the module to use for websocket connections and i don't find any alternative. But time is changing, technology is evolving, so i wonder if this project is still maintained.

Hasn't the time come for socket.io 3.0? I think about:

• Is everything still up-to-date? What about security?
• Can we drop support for older browsers, especially at socket.io-client (Drop http long-polling maybe? Drop support for IE 9, 10 and 11?)
• Shouldn't RxJS be used widely?
• Shouldn't socket.io-client be treeshakable, e.g. for use with Webpack? So we can only import what is needed instead of full 61kb.
• Typings are needed
• Are further performance improvements possible? (Both for socket.io and socket.io-client)

What about an rewrite of socket.io in TypeScript? At least socket.io does seem to be a relative small project. In contrast I want to mention the evolution of something like RxJS: Constantly reinventing itself, reducing bundle-size, treeshakability, performance etc. etc.

[darrachequesne]

Yes it is! Most recent work has gone into the website, as I think most of the open issues are related to the lack of proper documentation.

Is everything still up-to-date? What about security?

Every dependency should be up-to-date, but I'll check!

Can we drop support for older browsers, especially at socket.io-client (Drop http long-polling maybe? Drop support for IE 9, 10 and 11?)

Dropping XHR polling would basically mean using WebSocket only, but in that case it would be better to use the "raw" WebSocket API (instead of a 15kb gzipped bundle on the client-side). Dropping support for older IE versions wouldn't result in a big removal of code I fear, but I guess we could.

Shouldn't RxJS be used widely?

You mean, providing a RxJS API within Socket.IO?

Shouldn't socket.io-client be treeshakable, e.g. for use with Webpack? So we can only import what is needed instead of full 61kb.

As with dropping older IE versions, I'm not sure it would result in a much lighter build, but we could try!

Typings are needed

You mean, https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/socket.io ?

Are further performance improvements possible? (Both for socket.io and socket.io-client)

Some ideas for the v3 release are listed there. Basically, the rewrite to ES6 could be swapped to a rewrite in TypeScript, but in both case all related projects are concerned:

• https://github.com/socketio/socket.io
• https://github.com/socketio/socket.io-client
• https://github.com/socketio/socket.io-parser
• https://github.com/socketio/socket.io-adapter
• https://github.com/socketio/socket.io-redis
• https://github.com/socketio/engine.io
• https://github.com/socketio/engine.io-client
• https://github.com/socketio/engine.io-parser

[joacim-boive]

IE11 is still, unfortunately, very much alive!
Please don't drop support for it just yet.

[MickL]

@joacim-boive You could still use 2.0 if you want IE support. Many frameworks dropped IE support with their latest versions.

@darrachequesne Didnt expected this, great to hear! I would totally prefer TS over ES6/7. I wonder why the client is 60kb, no way to make it treeshakable? With RxJs i meant within socket.io code not for the „enduser“. Maybe it could be more reactive and this could possibly reduce a lot of code and male things more simple. The enduser can still use socket.on() or decide to use RxJS fromEvent(socket) instead as it is now. Also may it make sense to create documentation out of the source code comments?

To let me contribute i would love to see some graphics when what is happening and why. Long polling, handshake, upgrade websocket connection etc etc. If then everything is modular with single responsibility and made with TypeScript someone who is not familiar woth network-technology could still help contributing like improving bundle size or performance.

Thats a lot of projects. Personally i would go one by one and start only with js client maybe and all others could still use fantastic 2.0. Also maybe another module could catch breaking changes so 2.0 still works with 3.0 server, e.g. see rxjs-compat.

Btw the new website was so confusing and disapointing for me at first: I thought „documenation“ is everything and mostly so many functions are missing. Took me a while to notice the page „api“ which was exactly what i was looking for.

[MickL]

Closed, contiued discussion here: #3250

[darrachequesne]

@MickL I started to document the relationships between modules here: https://socket.io/docs/internals/ It is obviously far from complete, but that's a starting point.

Running webpack-bundle-analyzer on the client gives:

Which shows that the main sources of code are under our control:

• https://github.com/socketio/socket.io-client
• https://github.com/socketio/socket.io-parser
• https://github.com/socketio/engine.io-client
• https://github.com/socketio/engine.io-parser

Btw the new website was so confusing and disapointing for me at first: I thought „documenation“ is everything and mostly so many functions are missing. Took me a while to notice the page „api“ which was exactly what i was looking for.

Sorry to hear that! I'm open to suggestion for how to make the website clearer.

[coltenkrauter]

Is this project still maintained?

[darrachequesne]

@coltenkrauter yes it is! I'll have a lot more time to dedicate to the project in the next few months, I'm going to publish a roadmap soon.

[coltenkrauter]

Fantastic @darrachequesne, I love what you've done here.