Hacker News Reader

Comment by willsmith72 | Hacker News Reader

i don't agree at all. nodejs backends are as performant as you build them. the whole premise of node was async io, so if you're doing a bunch of blocking stuff then yeah, you're going to have issues. otherwise there's nothing innately non-performant about the platform.

it's impossible to debate more without going into details on your performance issues. typical backend architecture for any platform these days is the scalable container model, if you wanted scale-to-zero i wouldn't necessarily use node because of cold starts.

prisma can be great, can be slower than writing your own query, but that's the whole point of it. most of the time, it works and you can forget about queries and typings. when it doesn't, you can just eject to raw sql anytime you want.

i'm not a total nodejs fanboy, and have used more jvm (java/kotlin/scala) in my life, but if i was building a web-app today i'd absolutely consider node for all the reasons the author listed

View on HN

Nodejs backends are not "as performant as you build them" nodejs is slow! This is an undeniable fact. If you ever have to do anything computationally intensive, which every backend at some point will nodejs will become the bottleneck.

It's as fast or even faster than Java that you mentioned. In my experience, comparable to Golang.

Generally anyone that references performance/bottlenecks without data, they’re just parroting their bias. This post is “nu uh!”, but with more words.

Nodejs is slooooooooooooooooooooooooooooow. [0]

[0] - https://www.techempower.com/benchmarks/#hw=ph&test=composite...

What do you think about how well uWebSockets.js performed in the TechEmpower benchmark? Just js is admittedly experimental, but it has the fourth highest score, and the highest score of any non-Rust framework as well which I found interesting. Elysia (a Bun framework) did pretty well too.

Deno would have probably scored well too (it uses Rust's Hyper crate under the hood), but they're only running a single instance of the server despite Deno supporting the Linux SO_REUSEPORT socket option, which is important because the test is run on three servers with Intel Xeon Gold 5120 Processors that have 14 cores and 28 hyperthreads [0].

[0] https://github.com/TechEmpower/FrameworkBenchmarks/tree/9f0c...

Just go to its repo https://github.com/uNetworking/uWebSockets.js and see the uWebSockets submodule dependency that it's written in C++ (90.9%) and C (6.8%)...so sure, a "fair" comparison indeed with vanilla implementation!

Ok...Node is itself written in C++. The V8 and JavaScriptCore JS engines have no concept of a server (they were designed for web browsers), so under the hood JS runtimes implement servers in a lower level language capable of interfacing with Linux syscalls. Bun uses Zig, Deno uses Rust, Node uses C++, etc. I don't think that necessarily makes this an unfair comparison. The database drivers used in these benchmarks are also usually written in C++. Look at the repo for the native Postgres binding for Node: https://github.com/brianc/node-libpq

‘nodejs is slow’ isn’t engineering.

‘nodejs is too slow’ is high school level backward rationalization.

‘nodejs is too slow for my use case’ is getting there.

Most stuff we engineer maxes out the database way way waaaay before it saturates its CPU capacity regardless of the language used. You’d better know very well that you’ll be vulnerable to this as a business, otherwise your inefficient competitors will take your money faster than you can build value.

I repeat

> the whole premise of node was async io, so if you're doing a bunch of blocking stuff then yeah, you're going to have issues.

I would not use prisma for anything until they fix https://github.com/prisma/prisma/discussions/12715

I wouldn't use find commands beyond the simplest Join. The beauty of Prisma is raw queries, because they're compiled and type-checked against your Entities. That's the whole appeal, IMHO.

Reply on news.ycombinator.com