Comment by soltanov
15 hours ago
I'm curious though: for people still choosing Deno today, what is the one thing Node still doesn't give you?
15 hours ago
I'm curious though: for people still choosing Deno today, what is the one thing Node still doesn't give you?
Generally, a bunch of batteries included out of the box, in which I don't have to care about installing and configuring a toolchain full of third-party deps in order to do stuff like formatting or CSV imports. (Yes, I'm counting the JSR stdlib when I say this. I did say "third-party." This isn't, and in fact it is intentional about being cross-runtime where possible.)
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.
- I replaced a mess of prettier config files, eslint config files, tsconfig files, npm install scripts for all the above plus the typescript eslint config plugin for deno fmt, deno lint, deno check. It's nice to have that all in one place.
- 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.
There is no "one thing", there's many things, the top of the list being:
- 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.
> - packages in workspaces can be used as dependencies without compilation (node's type stripping doesn't support this)
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.
That must be new. It did not work when I last tested type stripping, earlier this year using pnpm as well. And to be fair bun didn't work either.
Glad if it's working now regardless though, I also see some experimental support for coverage in the docs now.
Sandboxing and being more aligned with web standards, though admittedly on the latter I haven't checked back in on node with to see if there's been a push towards having the same tools as the browser engines instead of import('garys-crypto') etc
Security, as outlined by OP?
Well I don't think Deno or Bun (or Node) does this, but I believe both Deno and Bun have tickets to offer it someday (while Node hates the idea passionately) ...
... a way to document/comment the central project config file (ie. package.json).
I reluctantly do anything with JS/TS but if I have to, I'll pick Deno because I'm sick of needing to install a dozen dependencies which then require their own thousands of dependencies.
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.