Closed ronag closed 4 years ago
https://github.com/uNetworking/uSockets/issues/103
I have no interest in doing this, it is a very bad idea IMO. There are two outcomes - either nobody cares, or it becomes popular and everyone starts wrapping it in ways that entirely void any benefits. Then ExpressJS and Socket.IO will capitalize on the hype and state that they are running it, even though it will entirely bottleneck in their codebase.
Then you end up in the same situation as uWS v0.14 - everyone use it everywhere even though it doesn't make any improvement whatsoever, because everyone still use it with Socket.IO. You basically dilute a brand for nothing and nobody sees any improvement and now everyone associate the name with nothingness.
The only way to improve the situation in nodejs is to take away responsibility from scripting and move to systems programming, where it can be reimplemented correctly (see uWS.js).
The only reason uWS.js is an improvement is because it implements the entire stack in systems programming languages and only expose the very high level features to script (pub/sub, routed URL endpoints).
So scripted apps can express high level intents like "publish this message to all subscribers of green", and have that be done efficiently in capable languages.
Fair enough. Thanks for the explanation.
I would rather see things like a Redis connector written in C against uSockets and then wrapped as a whole for JavaScript, or something like that. Never uSockets itself
With javascript bindings I think this could be a possible alternative to the
net
andtls
socket implementations in Nodejs, i.e. auSockets.js
.