Hacker News Reader

Comment by alberth | Hacker News Reader

Is NodeJS becoming more performant & efficient - as competition from Bun/JustJS/etc heat up?

It was already pretty performant. The issue is as always runtime type checking. For serious stuff you really want that. Also, async everything is not fun. Simple code executed in a thread pool or whatever is so much easier to reason about.

Worker threads have been around for a bit:

https://nodejs.org/api/worker_threads.html

yes and slow AF. also nobody is gonna use worker threads without async to handle API requests in NodeJS - why would you use nodejs then?

> Simple code executed in a thread pool or whatever is so much easier to reason about. reply

Hard disagree. It's much easier to reason about async await because you don't need to worry about preemption. You (generally) don't need mutexes or anything like that.

hard disagree. :)

When do you have to worry about synchronization? You don't. Pull DB connection from pool, etc, done.

Async await has colored functions, promises, and other atrocities.

Even if I have some locking primitives somewhere I'll GLADLY take that over the fucking mess of async stack traces and code executed "next tick" with no trace.

Performant in what sense?

as in easy to handle tens of thousands requests a second with a few DB calls on a smallish server? do you want a PHD thesus on what performant means?

Node JS caps at less than 10K RPS...

oh what machine? with how many workers? doing what?

search for "node" on this page: https://www.techempower.com/benchmarks/#section=data-r21

Rather than searching "node" on TechEmpower I do my own comparative benchmarks in a given environment.

Node always loses. Every time. To everything. It reliably loses to Java, Python, and even other JavaScript engines. Which is why I asked... performant compared to what?

Express, on Linux, with one worker because that's how you benchmark apples-to-apples. Node 20, with plenty of RAM and CPU, not that it uses it.

Reply on news.ycombinator.com