Hacker News Reader

Comment by warkanlock | Hacker News Reader

In my experience, Node.js generally performs very well for most use cases although when it comes to data manipulation (or similar use cases), performance often goes down the hill, becoming the primary bottleneck nearly every time. It's simply not the right tool for the job.

The beauty of this is that it allows teams to isolate and optimize just the problematic portion of the code, preventing them from going down a rabbit hole of extensive changes that can be more harmful than beneficial.

NAPI is such a good tool for this; that I've been advocating the use of it to my team since forever.

View on HN

> In my experience, Node.js generally performs very well

Hard disagree here. Node is extremely fast to get up and running with, has as close to 0 barrier to entry as possible, and doesn't suffer from slow startup times that plague JVM languages. It can also be fast for tight loops.

But in the experience I've had with it"generally", it's orders of magnitude slower than other languages. A hello world with express.js and gin in go are a full order of magnitude apart, and the express app with default settings dies under a load test that I would describe as "very light".

Stories like this thread are common in the JS world where technically it can be rewritten to be faster, but like with Bun, esbuild, and many other examples we've seen here on HN, a better language choice makes an enormous difference. And to me, the only time node is the right tool for the job is if you have a team of JavaScript developers who can't learn another language

Depends what you're comparing it to though. That same Node.js application will likely be an order of magnitude faster than a similar one in Python or Ruby.

So, when it comes to a technology that works well, I think it should be easy to adopt for the whole team, Node.js won here even against Go. In my experience, Go seems to fit quite well there, although there are plenty of developers out there without Go skills.

But let's face it: In most of the projects we work on, clients don't need to handle millions of requests from distributed systems and geolocated servers all over the world. Generally, our clients just want a CRUD that is a little more elegant than Excel and can help them solve their real-world problems.

IMO if someone from your team tells you that you cannot do something with an average of ~10,000 req/s [1] (around that number is the consensus nowadays for Javascript whereas Bun is highly superior to everyone here), you may be solving the problem in the wrong way.

[1] That's around 36 million requests per hour!

> doesn't suffer from slow startup times that plague JVM languages

Java ecosystem now has AOT compilation.

We have a golang service that we use for auth - it simply generates JWTs. Our main application is in kotlin.

Our golang app starts up, binds a port, signs the jwt and shuts down before our kotlin app even hits our code.

Rather than keep on restarting your Kotlin app, you should run it as a server, then you'd also benefit from JIT compilation.

Then it would serve requests at the same speed, if not faster, as your Go app.

> the only time node is the right tool for the job is if you have a team of JavaScript developers who can't learn another language

I’d push back just a little on that. If you’re on a small team writing a small app, having the frontend and backend both be in js/ts, and in the same repo, can be a big help.

Yeah I made a very broad statement. I don't think the value in having your frontend and backend in the same language is there though. Your frontend _has_ to be js/ts, but your backend should be a language you know. If you've spent the last 10 years working with rails, then rails it is. If you know go, then go. If you know node, are on a small team with a tight timeline, then _maybe_, but honestly I think I'd still rather rails or go.

Completely agree about the same repo though.

Reply on news.ycombinator.com