Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

41–50 of 448 posts

Re: Modern Node.js Patterns

#41
Nice post! There's a lot of stuff here that I had no idea was in built-in already.

I tried making a standalone executable with the command provided, but it produced a .blob which I believe still requires the Node runtime to run. I was able to make a true executable with postject per the Node docs[1], but a simple Hello World resulted in a 110 MB binary. This is probably a drawback worth mentioning.

Also, seeing those arbitrary timeout limits I can't help but think of the guy in Antarctica who had major headaches about hardcoded timeouts.[2]

[1]: https://nodejs.org/api/single-executable-applications.html

[2]: https://brr.fyi/posts/engineering-for-slow-internet

Re: Modern Node.js Patterns

#42
post #27

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

node fetch is WAY better than axios (easier to use/understand, simpler); didn't really know people were still using axios

Right?! I think a lot of devs got stuck in the axios habit from before Node 18 when fetch wasn't built-in. Plus axios has that batteries included feel with interceptors, auto-JSON parsing, etc. But for most use cases, native fetch + a few lines of wrapper code beats dragging in a whole dependency.

Re: Modern Node.js Patterns

#43

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

As a library author it's the opposite, while fetch() is amazing, ESM has been a painful but definitely worth upgrade. It has all the things the author describes.

Re: Modern Node.js Patterns

#44
post #30
post #27

Earlier quoted context omitted.

node fetch is WAY better than axios (easier to use/understand, simpler); didn't really know people were still using axios

I do miss the axios extensions tho, it was very easy to add rate-limits, throttling, retry strategies, cache, logging .. You can obviously do that with fetch but it is more fragmented and more boilerplate

Totally get that! I think it depends on your context. For Lambda where every KB and millisecond counts, native fetch wins, but for a full app where you need robust HTTP handling, the axios plugin ecosystem was honestly pretty nice. The fragmentation with fetch libraries is real. You end up evaluating 5 different retry packages instead of just grabbing axios-retry.

Re: Modern Node.js Patterns

#45
post #30
post #27

Earlier quoted context omitted.

node fetch is WAY better than axios (easier to use/understand, simpler); didn't really know people were still using axios

I do miss the axios extensions tho, it was very easy to add rate-limits, throttling, retry strategies, cache, logging .. You can obviously do that with fetch but it is more fragmented and more boilerplate

Sounds like there's space for an axios-like library built on top of fetch.

Re: Modern Node.js Patterns

#46
post #30

Earlier quoted context omitted.

I do miss the axios extensions tho, it was very easy to add rate-limits, throttling, retry strategies, cache, logging .. You can obviously do that with fetch but it is more fragmented and more boilerplate

Sounds like there's space for an axios-like library built on top of fetch.

[dead]

Re: Modern Node.js Patterns

#47

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

As a library author it's the opposite, while fetch() is amazing, ESM has been a painful but definitely worth upgrade. It has all the things the author describes.

Interesting to get a library author's perspective. To be fair, you guys had to deal with the whole ecosystem shift: dual package hazards, CJS/ESM compatibility hell, tooling changes, etc so I can see how ESM would be the bigger story from your perspective.

Re: Modern Node.js Patterns

#48
The LLM made this sound so epic: "The node: prefix is more than just a convention—it’s a clear signal to both developers and tools that you’re importing Node.js built-ins rather than npm packages. This prevents potential conflicts and makes your code more explicit about its dependencies."

Re: Modern Node.js Patterns

#49
post #38

I think slowly Node is shaping up to offer strong competition to Bun.js, Deno, etc. such that there is little reason to switch. The mutual competition is good for the continued development of JS runtimes

Slowly, yes, definitely welcome changes. I'm still missing Bun's `$` shell functions though. It's very convenient to use JS as a scripting language and don't really want to run 2 runtimes on my server.

Re: Modern Node.js Patterns

#50

The LLM made this sound so epic: "The node: prefix is more than just a convention—it’s a clear signal to both developers and tools that you’re importing Node.js built-ins rather than npm packages. This prevents potential conflicts and makes your code more explicit about its dependencies."

so in other words, it's a convention
Post reply on HN