theturtle32 / WebSocket-Node

A WebSocket Implementation for Node.JS (Draft -08 through the final RFC 6455)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

This pkg appears abandoned. I recommend switching to "ws", it's a very similar implementation

GriffinSego opened this issue · comments

This pkg appears unfortunately abandoned, not a word from devs, not a commit in 4 years, and the only action in 2023 has been 2 closed issues. A shame, after I have relied on it since 2017.

I recommend switching to npm "ws", it's a very similar implementation and takes almost no effort to switch from "websocket" to "ws" because the events and syntax is almost identical.

Just wanted to post for anyone else wondering why their ws implementation isn't staying up with the newer versions and specs as they gradually are enforced as minlimits in newer services.

Hi, whilst I understand your opinion I would personally hesitate on recommending one or another package based upon your experience. We have been working with Brian on this since 2011, and whilst you may consider it abandoned, it most certainly is not in our opinion. The lack of updates to this module are in part due to it's extremely stable and reliable code, upon which we have relied upon for our own business. We have this actively deployed today with well over 100k 24x365 always on clients and server instances regularly handling 32k concurrent connections per process. I personally was involved in the process that finally led to the WebSocket RFC (indeed the 120+ attempts to come to an agreement on the standard) and have built our offering based upon it's functionality, and for the most part this module has remained stable and fully functional for the global scale production deployments we have today.
Our own experience with ws (which we regularly evaluate for our use case) was less than successful; whilst it offers out of the box support for advanced functionality like perMessageDeflate, it consumed all available server resources and did not scale to the 512k connections per server we support today. Whether you choose to stay or go with this package is your own choice, but I just don't agree with you being in the position to publicly recommend others to follow your lead; ultimately it is up to everyone to make their own choice on suitability and act accordingly.

@rgillan thanks for jumping in here, I appreciate your coming to my defense, and the stellar review as well.

Indeed, it has been a little while since I've published an update. There haven't been any glaring issues requiring it, things have been pretty stable for a while. It wouldn't hurt to do a bit of a revision, update some of the code style to more modern JS -- this library was written in ES3 -- and at the very least, expose it a more modern API option that would fit in a little more nicely with current language capabilities. Async iterables, for example, so you can use for await...of to loop over incoming messages.

We'll see if I can get time to work on that soon.

I just don't agree with you being in the position to publicly recommend others to follow your lead;

I have not switched to ws, I am not advising others to "follow my lead", and I still use websocket for my biggest personal projects. I wanted to offer a helpful pointer to newcomers finding this repo and choosing what pkg to use. If it ain't broke, don't fix it mentality.

In general, the best (and indeed sometimes only) metrics that can be used to determine how well maintained any pkg is are latest commit date and issues. I can see that this could be an edge case where a finished package without need for updates (and therefore issues) could seem deceptively unmaintained.

I would like to extend an apology to @theturtle32 if my issue seemed like an attack of any sort, it was not intended to be one. My projects dependent on websocket have been stable without need for changes since their codebases were born in 2017. I am pleased to hear that you intend to maintain the package, as that will doubtlessly save me and countless others from having to migrate to other less performant alternatives.

In addition - Thank you @rgillan for including your personal benchmarks. I was under the impression that ws is only a minor performance downgrade from websocket, so I appreciate the correction there. I do wish you hadn't switched straight into tribal defense mode regardless when a single "hey, no it's not, it's currently fully stable" would have sufficed, but this is the internet. This is still the most civil conversation I've seen today.

Sorry, 'I recommend switching to "ws"' was a little misleading then :). Happy to help, just maybe next time don't raise an issue on someone else's module, you could always ask the maintainer directly. Cheers