>It is productive and elegant, sure, but lacks in performance. Emerging are projects like Fastify, and hundreds alike. They all aim to provide what Express does, at a lower performance penalty. But that’s exactly what they are; a penalty. Not an improvement. They’re still strictly limited to what Node.js can provide, and that’s not much as compared to the competition
The whole article is badly written.
First it assumes that the lower performance is something insufferable -- when in most cases, and for most project, it doesn't matter at all.
Then it fails to understand the important of developer pool, convenience, ecosystem, etc, as if JS and Node could be willy nilly replaced by Golang for every project.
Third, it pisses (as above) on Node web framework projects, just because Node.js has a performance top (as a single process lower than Golang.
Also the importance of the overall architecture for performance is not accounted at all -- or the fact that as long as you add some database queries the speed benefit over Node diminishes...
He obviously went and reviewed the rest, or how would he know about the uWebsockets portion? His point is that the article is poorly written enough that he had no desire to finish it, and I fully agree. More information and less disparaging fluff would make this piece much more attractive to the engineers of the world.
For Node to be a “sluggish Golang” in the first place, it would have to be otherwise functionally equivalent to Golang, which it is not. Writing your own TCP and SSL layers is also kind of nuts if your motivation for doing so is to optimize your Node apps.
This. It's an apples to oranges comparison. People often write in Node for the speed that they can develop. Golang's current language design does not aim for development speed, although I think it's getting better/easier.
I have to agree... the fact is, Node isn't the best at anything in terms of raw performance and won't be. What it is, however, is good enough for almost everything.
Node/JS offer some serious advantages. An expansive ecosystem of modules for which to build applications quickly. A well-known scripting language that allows for fast development and turn over. A language that allows for less distraction and context switching when going from one layer to another in terms of full stack development. Allows for a complete feature set to be in a single language with less disconnect to the front end.
I won't say there isn't a place for other languages. I will say that applications created with JS front and back using Node as at least the direct API/middle tier tend to be up and running faster, and perform well enough for most tasks if horizontal scaling is already part of the overall design of the application.
It also does well for cross platform scripting and orchestrating CPU intensive tasks.
If it was just, "I wrote a custom network stack to make your Node apps run faster", that would be something, but Golang is completely irrelevant to the question.
uWebsockets is an awesome project! Been following it since the start pretty much, And I'm really glad more people out there care more about performance than throwing more servers at the problem.
The whole article is badly written.
First it assumes that the lower performance is something insufferable -- when in most cases, and for most project, it doesn't matter at all.
Then it fails to understand the important of developer pool, convenience, ecosystem, etc, as if JS and Node could be willy nilly replaced by Golang for every project.
Third, it pisses (as above) on Node web framework projects, just because Node.js has a performance top (as a single process lower than Golang.
Also the importance of the overall architecture for performance is not accounted at all -- or the fact that as long as you add some database queries the speed benefit over Node diminishes...