I recently moved a Bun project to Node. When I picked Bun I was convinced by their built-in support for TypeScript, modern standard library including a testing framework, better performance and compatibility with the NPM ecosystem.
In practice we had multiple issues with Playwright, our main dependency. Their test coverage data is just wrong. And what finally lost all my faith in the project was the infamous overnight port to Rust. No problems with Rust, I'm a huge fan, the problem is their lack of responsibility/accountability to their user base running actual software on the platform.
Thankfully I built everything with a "port to node in case of emergency" design and it paid off. Moved to Node and have not looked back.
I'm also not in the JS ecosystem but it seems like the issue is that there are different standards for the parts of JavaScript that are outside the browser ecosystem. For example, the main article here talks about the Deno filesystem access API and Dino's http serve functionality.
Node and Deno both use V8 for the browser-compatible JS execution, and then they add their own APIs on top for using it as a backend language. It seems that Bun uses JavaScriptCore (from Safari) instead of V8 (from Chrome) but I imagine the main differences are still the system APIs.
I consistently enjoy David Bushell's writing. However, the first thing I always think when seeing his domain on lobsters is: "Wow, this person must really hate dbus!" ^^ Only a split second later do I remember that I know this domain :)
I had this phase, a few years ago, where I really was into JS build/dev tooling. The whole ESM/CJS, TypeScript support and slow dev times, got me into a lot of fun stuff like Vite, ESBuild, Deno, Turbopack, CSS tooling. And it's all fun but it also ended up not really improving anything. I remember trying out Bun and thinking wow I took Node's stability for granted. And thus returned to following whatever the team liked the most, hoping that Deno would make a bigger splash.
And then around Node v20-22...Node included some really nice things! And the need for other (fast-moving) runtimes kinda dwindled away.
I'm pretty happy with JS tooling these days, it can still be a lot, but with the experience gained I feel like I can communicate very well why a project might not need a tool.
Still Deno holds a really nice place(it just includes so many great defaults!), and maybe OSS Deno can thrive in a similar way Biome or Servo does.
I’ve really been enjoying Deno recently. Its JSX bundler produces better JS than any other thanks to an innovative optimization they call precompiling. My draft blog post on that:
There are a couple of other things. I was writing a quick script the other day and it was super nice to be able to import "npm:foo" without having to create a package.json or a node_modules folder. The homepage advertises its performance is much better than node or npm. I like deno.json more than package.json since the import block maps nicely to a browser importmap. None of this is super new, so maybe the author has used these features for longer than me and is bored by them.
I wish this post was more substantial about what advantages node has over Deno. The author claims Node is 15% faster on his workload but there other workloads (see above link or Deno homepage for examples) where Deno is faster.
I don’t know why Deno integrates with ZSH or what is broken about it; Deno supports NPM or URL imports if JSR has issues; and I’d be interested in hearing about bugs but just alluding to them isn’t interesting.
The author has used Deno more than me and has linked to some of their missteps, but I’m optimistic about using it going forward.
IIRC (with emphasis on the if – I use zsh or, if that’s not available, a POSIX sh fallback for most everything!), if you set a $BASH_ENV file to declare your aliases in, scripts will inherit those. (Zsh has a dedicated .zshenv, so the file/variable needn’t be actively set, at least as far as I understand)
I didn’t run into those issues with Deno, so I guess I’ll keep using it. It does support package.json instead of deno.json now, so that might be a decent compromise?
To me, Deno's permission system does not seem to be fine-grained enough to be actually helpful. It's like a really lo-fi version of a capabilities system. Do you find it to be useful?
PNPM also blocks post-install scripts. Does NPM still yolo those?
Nope. (But you have to manually upgrade npm to get the off-by-default behavior and not just a warning; npm 12 shipped too late to be included with Node 26.)
I would also like to not depend on Deno for reasons outlined in the article, but I have a couple static websites I made using Lume, which is my SSG of choice. Is there an alternative that works with Node? There is 11ty, but it's so much more complicated to configure and set up compared to Lume.
The official Node docs recommend piping an internet script straight to bash (we never learn)
never learn what exactly? you’re about to execute a bunch of arbitrary code downloaded from the internet anyway, why does is matter if the first chunk is a shell script?
again, all of this is also true of the binary you’re about to download. even if you verify the checksum, where did you get the checksum from? was it any more trustworthy than the binary itself?
gcollazo | 9 hours ago
I recently moved a Bun project to Node. When I picked Bun I was convinced by their built-in support for TypeScript, modern standard library including a testing framework, better performance and compatibility with the NPM ecosystem.
In practice we had multiple issues with Playwright, our main dependency. Their test coverage data is just wrong. And what finally lost all my faith in the project was the infamous overnight port to Rust. No problems with Rust, I'm a huge fan, the problem is their lack of responsibility/accountability to their user base running actual software on the platform.
Thankfully I built everything with a "port to node in case of emergency" design and it paid off. Moved to Node and have not looked back.
Relax | 4 hours ago
As someone completely outside of the JavaScript ecosystem, what's the challenging part of changing runtimes?
abrambleninja | 4 hours ago
I'm also not in the JS ecosystem but it seems like the issue is that there are different standards for the parts of JavaScript that are outside the browser ecosystem. For example, the main article here talks about the Deno filesystem access API and Dino's http serve functionality.
Node and Deno both use V8 for the browser-compatible JS execution, and then they add their own APIs on top for using it as a backend language. It seems that Bun uses JavaScriptCore (from Safari) instead of V8 (from Chrome) but I imagine the main differences are still the system APIs.
pcaisse | 4 hours ago
I did the exact same thing!
Mine was just a learning project but I ported it away from Bun and back to Node to get the bad taste out of my mouth and it was surprisingly smooth.
senekor | 10 hours ago
I consistently enjoy David Bushell's writing. However, the first thing I always think when seeing his domain on lobsters is: "Wow, this person must really hate dbus!" ^^ Only a split second later do I remember that I know this domain :)
zk | 9 hours ago
Haha! Same here! Every single time! :D
frogulis | 9 hours ago
If not that, then wondering what kind of cool new database tooling "DBU shell" might be
andyc | 6 hours ago
That's what I thought! I was wondering about this domain name, not realizing it is a person's name ... What's this newfangled shell ??
Likewise, I heard that many people didn't realize "godbolt" was the last name of the author of Compiler Explorer: https://godbolt.org/
They perhaps thought it was some kind of compiler analogy :-)
strugee | 5 hours ago
TIL! Aka, you heard right :D
Gracana | 4 hours ago
Seems like the kind of fastener you'd use along with a Jesus nut. https://en.wikipedia.org/wiki/Jesus_nut
wrs | 5 hours ago
But…NPM is also a Microsoft product.
zetashift | 10 hours ago
I had this phase, a few years ago, where I really was into JS build/dev tooling. The whole ESM/CJS, TypeScript support and slow dev times, got me into a lot of fun stuff like Vite, ESBuild, Deno, Turbopack, CSS tooling. And it's all fun but it also ended up not really improving anything. I remember trying out Bun and thinking wow I took Node's stability for granted. And thus returned to following whatever the team liked the most, hoping that Deno would make a bigger splash.
And then around Node v20-22...Node included some really nice things! And the need for other (fast-moving) runtimes kinda dwindled away.
I'm pretty happy with JS tooling these days, it can still be a lot, but with the experience gained I feel like I can communicate very well why a project might not need a tool.
Still Deno holds a really nice place(it just includes so many great defaults!), and maybe OSS Deno can thrive in a similar way Biome or Servo does.
matthiasportzel | 7 hours ago
I’ve really been enjoying Deno recently. Its JSX bundler produces better JS than any other thanks to an innovative optimization they call precompiling. My draft blog post on that:
=> https://matthiasportzel.com/rendering-benchmarks
There are a couple of other things. I was writing a quick script the other day and it was super nice to be able to
import "npm:foo"without having to create a package.json or a node_modules folder. The homepage advertises its performance is much better than node or npm. I like deno.json more than package.json since the import block maps nicely to a browser importmap. None of this is super new, so maybe the author has used these features for longer than me and is bored by them.I wish this post was more substantial about what advantages node has over Deno. The author claims Node is 15% faster on his workload but there other workloads (see above link or Deno homepage for examples) where Deno is faster.
I don’t know why Deno integrates with ZSH or what is broken about it; Deno supports NPM or URL imports if JSR has issues; and I’d be interested in hearing about bugs but just alluding to them isn’t interesting.
The author has used Deno more than me and has linked to some of their missteps, but I’m optimistic about using it going forward.
leela | 10 hours ago
npm install-time lifecycle scripts can be disabled with the
allow-scriptssetting, and minimum package ages can be configured withmin-release-age.shdown | 7 hours ago
bash aliases don't work inside scripts, unless bash somehow thinks it's in interactive mode:
sstephenson | 5 hours ago
This is true for Bash scripts, but not for POSIX shell scripts.
(Bash runs in POSIX mode when invoked as
sh)dbushell | 3 hours ago
Maybe i confused the time i used symlinks to trick something. The aliases do help copy & paste when everything expects
npm.tauonmsdz | 6 hours ago
Depends on where you defined them, I think.
IIRC (with emphasis on the if – I use zsh or, if that’s not available, a POSIX sh fallback for most everything!), if you set a
$BASH_ENVfile to declare your aliases in, scripts will inherit those. (Zsh has a dedicated.zshenv, so the file/variable needn’t be actively set, at least as far as I understand)fanf | 6 hours ago
The bash manual says
skybrian | 9 hours ago
I didn’t run into those issues with Deno, so I guess I’ll keep using it. It does support package.json instead of deno.json now, so that might be a decent compromise?
KevinMGranger | 6 hours ago
Unless Node adds Deno's permission system, I see no reason to switch.
chenghiz | 5 hours ago
To me, Deno's permission system does not seem to be fine-grained enough to be actually helpful. It's like a really lo-fi version of a capabilities system. Do you find it to be useful?
derp_alert | 5 hours ago
Did you have issues with Node's permission system?
bakkot | 3 hours ago
Nope. (But you have to manually upgrade npm to get the off-by-default behavior and not just a warning; npm 12 shipped too late to be included with Node 26.)
npm also has this now although, infuriatingly, it is in units of days instead of seconds.
Some other handy things node has now:
util.parseArgsutil.styleText--env-filenode:testfetchFor most applications, most of the time, I don't need any dependencies at all, or at most just
express. It's pretty nice.lknuth | 2 hours ago
huh, sqlite is bundled now? What a sane idea that is...
tudorr | 2 hours ago
I would also like to not depend on Deno for reasons outlined in the article, but I have a couple static websites I made using Lume, which is my SSG of choice. Is there an alternative that works with Node? There is 11ty, but it's so much more complicated to configure and set up compared to Lume.
lilac | 6 hours ago
never learn what exactly? you’re about to execute a bunch of arbitrary code downloaded from the internet anyway, why does is matter if the first chunk is a shell script?
dbushell | 2 hours ago
yeah but piping it straight to bash without verifying the contents weren't modified isn't great, web hosting can be weak point
lilac | 2 hours ago
again, all of this is also true of the binary you’re about to download. even if you verify the checksum, where did you get the checksum from? was it any more trustworthy than the binary itself?