What does HackerNews think of uWebSockets.js?
μWebSockets for Node.js back-ends :metal:
It seems like they are promoting their own library and doing a bit of their own deception by including a small library in their tests. Particularly a library that was designed entirely to perform well at that particular usecase (high throughout for small bits of data).
I think what they mean is it uses uWebSockets.js, a Node.js module wrapping a C++ implementation.
- Code cleanliness: their code almost looks like code golfing. Hard to debug.
- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.
- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...
- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.
- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.
- WebSocket pub/sub: built-in with uWebSockets.js
There are better alternatives like the following:
uWebSockets.js beats both on performance benchmarks. In fact it beats everything based on Node's built-in http module, such as fastify, hapi, koa.
- Savings in bandwidth might be only noticeable if the demand for scale is real and you have already exhausted other optimizations available. Think of trade-offs, the performance gains might be there, but other factors count like how familiar is your team with it, how flexible or constricting it is, etc etc.
- WebSockets are easier to implement on the client-side, most developers are familiar with it, both in web app and mobile apps.
- Since WebSockets are bi-directional, it's easy to let client send any data (e.g. for debugging, tracing, monitoring) almost effortlessly any time you might need it (maybe not now, maybe in the future).
- WebSockets support binary data, you can use existing serialization formats like msgpack, or have your own binary serialization format.
- There are WebSocket web frameworks out there like uWebSockets (written in C & C++, has Node.js API), used by most trading platforms, which got better performance than most web frameworks out there.
- https://github.com/uNetworking/uWebSockets
- https://github.com/uNetworking/uWebSockets.js/
- https://github.com/uNetworking/uWebSockets/tree/master/bench...
On cross-domain communications, should be good as long as it's 12-factor where you got a session store / pub-sub mechanism that both servers can use.
As a node dev, if I'm chasing performance I'd look for libraries with c++ bindings, like uWebSockets[0] for example.
NodeJS internal apis also got cluster and worker_threads which are handy when distributing workload in multiple cores.
On the other hand if you're talking about faster dev speed, nodejs is ok too since i can reuse some modules in backend and frontend.
Of course golang has advantage in terms of types (i abuse assert in nodejs to makeup for this) and performance (i throw money on hardware instead, if really needed), but question is do you really need those right now? The answer greatly varies per project.
No need to write wrappers for Fetch, network errors and reconnects can be handled on high-level, handlers for each message type can be mounted and unmounted on useEffect hooks, all back-end jobs can notify the user in realtime, all session-based client-side data can be updated in realtime (in single or multiple open tabs).
I'm also using uWebSockets.js[0] which is great in terms of API design, stability, and performance. Their benchmarks[1] are just convincing. Highly recommend people using ExpressJS / Koa / whatever to try it.
[0] https://github.com/uNetworking/uWebSockets.js/
[1] https://github.com/uNetworking/uWebSockets/tree/master/bench...
/* * @type {Map} */
const map = new Map();
Like that.
Express JS is still shit, koajs and fastify are a little better, I used to use nodejs's internal http and https libraries directly but these days uwebsockets.js is what you'd want since it's mature enough already (used by top crypto exchanges).
https://github.com/uNetworking/uWebSockets.js/
And oh it comes with TS types which are cool.
from the benchmarks, deno looks similar to node in net/http perf. is there any specific reason you guys cannot get significantly more perf out of deno? (Alex has always said and shown that v8 is not the bottleneck).
does v1 mean that some of the existing architectural choices are frozen and any significant perf improvments become impossible?
At that time I found uws (https://github.com/uNetworking/uWebSockets.js) that easily got me to 10K easily, and I was like "I would rather bet on a community investing on efficient websocket event loop rather than me writing my own sh*t". Don't get me wrong; I love Golang! Seriously I love it so much I have been pushing my company to use Golang. I just don't want to glorify the language for being silver bullet (which it's fanboys usually do). I would never implement complicated business logic that involves many moving pieces. When my business requires dealing with shape of an object and mixing matching things to pass data around; I would rather choose a language that lets me deal with shapes of object. Go has it's specific use-cases and strengths, people advertising it as move it to go and it would be faster than Java/C#/Node.js etc. have not done it or have not dealt with complexity of maintaining it.
https://github.com/uNetworking/uWebSockets.js
EDIT:
Note that the blog post is from 2015. There are many optimization (Ignition and TurboFan pipeline) has been done in V8 since then, especially offloading GC activity to separate thread than NodeJS Main thread.
he's famous for trolling the Node & Deno repos (i think he's banned from both). he also refuses to participate in the benchmarks (despite being able to score very well) because he says their methodology is flawed.