Not needing to have opinions about the details has been one of the most freeing things when working on a project, even if it now means having a slight opinion about not wanting to use npm anywhere that I don't have to.
I realize at this point Bun offers a lot of overlapping "Node-like but with lots of extra niceties." But I happen to like that this one is actively trying to contribute stuff back to the core ecosystem -- the stdlib, initiatives like WinterCG, infrastructure like JSR (which is open source and at least a little bit more resistant to consolidation relative to npm)... Instead of just trying to extend it with a kitchen sink full of first-party features.
Like others here said, I don't think it's just one thing.
- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.
- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.
- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.
- packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
- a good permissions model for limiting access to system fs, net, etc.
- native WebGPU support (including building a windowed app without a web view)
- desktop gui builds that allow using Chromium embedded or WebView
- built-in linter, benchmark, coverage, etc.
Node does support this! Although it may depend on exactly you link the packages within a workspace — I use `pnpm` and it Just Works™. Because NodeJS looks at the resolved symlink to decide whether a project is in `node_modules` or not, if the symlink resolves to a package in the workspace, then NodeJS will do type stripping as normal.
In fairness, the documentation is very unspecific about this, so I just had to try it out and see what happens, but it does work.
I think NodeJS also has coverage these days, although I could be wrong there.
Glad if it's working now regardless though, I also see some experimental support for coverage in the docs now.
... a way to document/comment the central project config file (ie. package.json).
Even if I pick modern tooling, say Biome for linting and formatting, Vite for bundling and handling the build, Vitest for unit testing, and finally TypeScript.
Once that's done, it's then remembering the right values needed in package.json and tsconfig.json to do the right thing and Just Work TM. It's 2026 and all this slop still assumes I don't want ES modules.
I could spend a whole morning on this bullshit. With Deno, I don't have to.
I always contrast that with my preferred languages, like C#/.NET. Project setup takes literally a few minutes. Deno and .NET have that in common, there is a single CLI for it.
The Deno JSR/STD thing also has a whole collection of libraries and data structures I'd otherwise need to get from NPM.