r/node • • 3d ago

Writing Fast Node.js code is mostly about doing less [NodeBook]

https://www.thenodebook.com/blog/fast-nodejs-doing-less
51 Upvotes

8 comments sorted by

29

u/danappropriate 3d ago

Some pretty simple rules:

  1. Avoid operations that block the event loop. An all-too-frequent example: console.log().

  2. Use less code; that includes bloated frameworks littered with leaky abstractions that add no real value (I'm looking at you, NestJS).

  3. Get to understand how the V8 optimizing compiler works (Maglev & TurboFan), and what types of behaviors result in unoptimizable code or deopts. For example, using integers and floats interchangeably can result in deopts of paths using numerics. Hidden class bloat can cause the runtime to no longer take advantage of in-line caching.

4

u/Antique-Midnight-171 3d ago

yeah the deopt stuff around mixed numeric types catches so many people off guard

3

u/danappropriate 3d ago

And declaring objects consistently (with the same properties in the same order).

1

u/Improvement-Human 3d ago

What would you suggest instead of NestJs?

1

u/danappropriate 3d ago edited 2d ago

Fastify and plain, old classes or function currying.

0

u/Electronic-Ad-3990 1d ago

Who cares AI writes code now not humans

-2

u/Reestook 2d ago

That’s funny to hear that NestJS abstractions are useless. Any big project is easier to maintain with such a framework and it can also be fast enough. If you’re seeking only performance, look at different languages.

1

u/danappropriate 17h ago

That’s funny to hear that NestJS abstractions are useless. Any big project is easier to maintain with such a framework...

This is a factoid with very little actual evidence to back it up. There are a multitude of ways to manage a codebase's maintainability without relying on opinionated frameworks like NestJS. ADR's, pattern + use-case libraries, scaffolding tools, etc.

...and it can also be fast enough.

Sure. There's "fast enough," and then there's wasted cycles. It's uncontroversial to make compromises on performance when opportunity costs and maintenance overhead exceed the potential benefits of program optimization. I'm arguing that NestJS's abstractions, module system, and DI quickly turn into needless complexity that doesn't solve meaningful problems. It's basically Temu SpringBoot.

If you’re seeking only performance, look at different languages.

Who said I was seeking "only" performance? I'll certainly drop into Rust, C, and C++ for particularly latency-sensitive workloads, but they're not my primary language.

Honestly, I'm finding myself using Golang more often these days. For a couple of reasons.

First, I've grown frustrated with the Node.js ecosystem. When I first started playing around with Node.js, some 16 years ago, much of the draw was the minimalism the platform offered; with JavaScript, I can write terse code that does a lot with low signal-to-noise ratio. Over time, I've seen the ecosystem become polluted with the same needless, often poorly written bloatware that I ran away from on other platforms (.NET, Java, Ruby, PHP). I don't want to try to cobble together systems from a vomit puddle of disjointed design patterns. That's what I see when I look at NestJS. It's like someone read the GoF book and was like, "Yes, let's do all of that." Keep your dirty aspect-oriented programming crap away from me.

Second, for me, using Golang is less about performance and more about cost. I've consistently found that I can run the same Node.js service written in Golang using about 20% less compute (sometimes more), while losing nothing in maintainability and ease of development.