Will Node.js forever be the sluggish Golang? | Hacker News Reader

Will Node.js forever be the sluggish Golang?

medium.com

17 pointsalexhultman14 comments

>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...

I'm sorry the article wasn't up to your standards.

It's mostly the overall tone hammered on, e.g. starting with: "Will Node.js forever be the sluggish Golang?" which is click-baity.

In fact I gave up around the insults at various Express-successors, and missed that the main point of the article is the µWebSockets.js.

Why not go into that directly and skip the rest? That's what people would want to know, not that "Node is worse than Golang in raw performance".

I thought you said you had assessed the _whole_ article as bad? You didn't read past the ingress, the motivation of the work done.

I stopped around the graph ("No so called “web framework” for Node.js, whether Fastify or not, can surpass the red line").

It didn't seem to point to some novel work, just to be some kind of piss take on Node.

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.

Node.js is very popular and some companies with lots of I/O still prefer JavaScript, they have their business logic written in it.

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.

That's a good title. Golang is referenced many times in the text though, it's even plotted in the two graphs.

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.

Feels similar to comparing C# to C.

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.

Keep it up alex!

Thanks to OP and contributors for this progress on performance. What are still feature gaps and what is the roadmap?

Reply on news.ycombinator.com