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.
tyleo · 27m ago
This is great. I learned several things reading this that I can immediately apply to my small personal projects.
1. Node has built in test support now: looks like I can drop jest!
2. Node has built in watch support now: looks like I can drop nodemon!
gabrielpoca118 · 15m ago
Don’t forget the native typescript transpiler which reduces the complexity a lot for those using TS
kfuse · 4m ago
Node now has limited supports for Typescript and has SQLite built in, so it becomes really good for small/personal web oriented projects.
keysdev · 48m ago
About time! The whole dragging the feet on ESM adoption is insane. The npm are still stuck on commonjs is quite a lot. In some way glad jsr came along.
lvl155 · 37m ago
Thank you for this. Very helpful as I was just starting to dig into node for first time in a few years.
andrewmcwatters · 17m ago
ESM is definitely not a clear winner. Using them pointlessly requires you to rewrite entire swaths of code. Typical JavaScript toil nonsense.
You juniors can downvote me all you want, it’s obviously a waste of time. You can’t opt-in as you go, so they force significant engineering labor on mature projects.
mattnewton · 1m ago
isn’t this just like one of the few problems that is completely solvable today with LLM coding agents?
seattle_spring · 3m ago
"Anyone who disagrees with me is a junior engineer."
Just because a new feature can't always easily be slipped into old codebases doesn't make it a bad feature.
andrewmcwatters · 1m ago
It’s pretty obviously bad. There was no need to design such a bad module system and basically destroy the work of others for no benefit.
Yes, it’s 100% junior, amateur mentality.
chickenzzzzu · 47m ago
Yet more architecture astronaut behavior by people who really should just be focusing on ifs, fors, arrays, and functions.
triyambakam · 40m ago
Architecture astronaut is a term I hadn't heard but can appreciate. However I fail to see that here. It's a fair overview of newish Node features... Haven't touched Node in a few years so kinda useful.
chickenzzzzu · 34m ago
It's a good one with some history and growing public knowledge now. I'd encourage a deep dive, it goes all the way back to at least CPP and small talk.
While I can see some arguments for "we need good tools like Node so that we can more easily write actual applications that solve actual business problems", this seems to me to be the opposite.
All I should ever have to do to import a bunch of functions from a file is
"import * from './path'"
anything more than that is a solution in search of a problem
MrJohz · 3m ago
Isn't that exactly the syntax being recommended? Could you explain what exactly in the article is a solution in search of a problem?
flufluflufluffy · 33m ago
what? This is an overview of modern features provided in a programming language runtime. Are you saying the author shouldn’t be wasting their time writing about them and should be writing for loops instead? Or are you saying the core devs of a language runtime shouldn’t be focused on architecture and should instead be writing for loops?
programmarchy · 37m ago
One of the core things Node.js got right was streams. (Anyone remember substack’s presentation “Thinking in streams”?) It’s good to see them continue to push that forward.
chickenzzzzu · 32m ago
Why? Why is a stream better than an array? Why is the concept of a realtime loop and for looping through a buffer not sufficient?
bblaylock · 14m ago
I think there are several reasons. First, the abstraction of a stream of data is useful when a program does more than process a single realtime loop. For example, adding a timeout to a stream of data, switching from one stream processor to another, splitting a stream into two streams or joining two streams into one, and generally all of the patterns that one finds in the Observable pattern, in unix pipes, and more generally event based systems, are modelled better in push and pull based streams than they are in a real time tight loop. Second, for the same reason that looping through an array using map or forEach methods is often favored over a for loop and for loops are often favored over while loops and while loops are favored over goto statements. Which is that it reduces the amount of human managed control flow bookkeeping, which is precisely where humans tend to introduce logic errors. And lastly, because it almost always takes less human effort to write and maintain stream processing code than it does to write and maintain a real time loop against a buffer.
Hopefully this helps! :D
dwb · 11m ago
A stream is not necessarily always better than an array, of course it depends on the situation. They are different things. But if you find yourself with a flow of data that you don't want to buffer entirely in memory before you process it and send it elsewhere, a stream-like abstraction can be very helpful.
1. Node has built in test support now: looks like I can drop jest!
2. Node has built in watch support now: looks like I can drop nodemon!
You juniors can downvote me all you want, it’s obviously a waste of time. You can’t opt-in as you go, so they force significant engineering labor on mature projects.
Just because a new feature can't always easily be slipped into old codebases doesn't make it a bad feature.
Yes, it’s 100% junior, amateur mentality.
While I can see some arguments for "we need good tools like Node so that we can more easily write actual applications that solve actual business problems", this seems to me to be the opposite.
All I should ever have to do to import a bunch of functions from a file is
"import * from './path'"
anything more than that is a solution in search of a problem
Hopefully this helps! :D