Friendship ended with Deno, now Node is my best friend
47 points by FedericoSchonborn
47 points by FedericoSchonborn
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.
As someone completely outside of the JavaScript ecosystem, what's the challenging part of changing runtimes?
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 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.
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 :)
If not that, then wondering what kind of cool new database tooling "DBU shell" might be
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 :-)
Likewise, I heard that many people didn't realize "godbolt" was the last name of the author of Compiler Explorer: https://godbolt.org/
TIL! Aka, you heard right :D
Seems like the kind of fastener you'd use along with a Jesus nut. https://en.wikipedia.org/wiki/Jesus_nut
…one does not simply publish TypeScript packages to NPM. … TypeScript is a Microsoft product. … Nobody wants more Microsoft.
But…NPM is also a Microsoft product.
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:
=> 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.
npm install-time lifecycle scripts can be disabled with the allow-scripts setting, and minimum package ages can be configured with min-release-age.
Some scripts I use have hard-coded binary names, so I added two aliases:
alias npm=pnpm alias npx=pnpx
bash aliases don't work inside scripts, unless bash somehow thinks it's in interactive mode:
$ bash -c 'alias myecho=echo; myecho hello'
bash: line 1: myecho: command not found
$ bash -i -c 'alias myecho=echo; myecho hello'
hello
$
This is true for Bash scripts, but not for POSIX shell scripts.
% /bin/sh --version
GNU bash, version 3.2.57(1)-release (arm64-apple-darwin26)
Copyright (C) 2007 Free Software Foundation, Inc.
~% /bin/sh <<EOF
heredoc> alias x=echo
heredoc> x hello
heredoc> EOF
hello
(Bash runs in POSIX mode when invoked as sh)
Maybe i confused the time i used symlinks to trick something.
The aliases do help copy & paste when everything expects npm.
bash aliases don't work inside scripts
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_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)
The bash manual says
Aliases are not expanded when the shell is not interactive, unless the expand_aliases shell option is set using shopt
Unless Node adds Deno's permission system, I see no reason to switch.
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?
It allows me to restrict outbound network access to specific hosts / IPs, and that's all I really need. Maybe filesystem restrictions but I'd run any real workloads in a container anyway.
I must have missed the ability to allowlist specific hosts when I last looked, that does seem useful.
Did you have issues with Node's permission system?
I didn't realize Node had such a system, whoops.
It doesn't look like you can allow/deny network access based on IP / DNS though, no?
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?
yeah but piping it straight to bash without verifying the contents weren't modified isn't great, web hosting can be weak point
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?
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?
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.
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.)
minimumReleaseAge: 1440
npm also has this now although, infuriatingly, it is in units of days instead of seconds.
So if I were to TL;DR in the middle: Node got a glow-up, wow!
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.
it's 2026, why would I want to use something that goes out of its way not to support typescript?!