Deno is a JavaScript and TypeScript runtime, for those who don't recognize the name. Here's a review of Deno 2.6 vs competitors Bun 1.3 and Node.js 25:
Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.
Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.
It sounds a lot like DNT (https://github.com/denoland/dnt) which has existed for a long time, but having it in Deno cli does bring significant visibility.
This is a really odd change. Deno already supported installing npm packages, this only removes the "npm:" prefix requirement for cli commands. Considering the nightmare that is npm, I was quite happy for jsr to become the defacto registry for the Deno ecosystem. If anything I would've expected the "jsr:" prefix to be the default.
I wrap most node-isms and use deno as the runtime. Works well. If a project is pure typescript I just have deno run it. Extra options for security are great, installation scripts disabled by default, etc.
If you're using node directly, please stop. At a minimum use Bun.
With agentic work, there is little reason to use anything besides Rust and Typescript in any case. Room to disagree but type safety, memory safety, and a large corpus of work is critical. Agents need difficult errors and baked in patterns they navigate it easily. For UI, Typescript makes the most sense just because of the mass of design examples.
Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support.
I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?
Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.
Bun had some early (imo, extremely deceptive) benchmarks that showed it had really good performance compared to Node and Deno. Zig was also a fledgling hotlang and Bun managed to translate the Zig community into more energy behind Bun. In addition to that, the creator of Bun became a minor celebrity for spending probably over 12 hours almost every single day working on it.
Everything just came together at the right time really quickly and they managed to capitalize on it.
Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.
I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node.
Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now.
Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice
"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here).
Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.
Bun doesn't require special tooling since it uses standard TS and follows the Node conventions. With Deno you need special tooling for eg the weird import system and package manager.
Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc.
Finally, Bun overall has better performance and efficiency compared to Deno.
That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.
Just make it a habit to write your types in JSDoc and be done with it. It's so much nicer in every way. Typescript checks your types, you are incentivized to write some brief documentation, and (self promotion) if you use something like my library testy you get your JSDoc examples tested.
I think if Deno had held on to their initial values for a little longer the pressure towards node compatibility would have been mended by AI agents, because a lot of the pressure is the result of skill issues: if the only way you know how to set up is using express.js then any subsequent tool or runtime must provide a similar abstraction for a “smooth” transition, regardless of how bad the first solution was in the first place. Nowadays you introduce devs to new tech by delivering your product with a set of skills that in practice have replaced documentation and sometimes can be very good at showing better alternative approaches to whatever you’re building.
Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.
npm by default: When I tried Deno ~1-2 years ago - I immediately shinned myself on this and decided to wait for more sensible defaults. (I've not followed closely, just the basic story)
And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.
Deno rules, I write some tiny and mid-size web services using it. Works like a Swiss clock, the project ideology is well aligned with the Unix sprit.
In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.
What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.
It really is such a pleasure. It feels almost like a blend of JS and Go. Fast, flexible, slightly saner package management with more powerful capabilities than other JS/TS alternatives, a better security model, better standard library (so to speak)... And very fast. I love it.
A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second.
The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.
If Deno continues this trajectory then there is less and less reason to use it over Node.
Bartek from the Deno team here. Thanks for the feedback, I understand your frustration.
> The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.
Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.
While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.
The continuous performance improvements in Deno are really impressive. Node compatibility getting better with every release makes the transition a lot easier for existing projects.
I literally just discovered Deno today. I wish there was Deno for Python / WASM path was really mature. Maybe I'm missing something here, but trying to secure both a Python runtime and JS runtime for AI.
As someone who has used Deno on multiple hobby projects, I’m convinced Deno is where the JS ecosystem should be heading.
Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.
It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).
My perspective is that of an user, not a developer. I use Deno since yt-dlp required a JS engine and recommended it. So while I don't use it for development, I have to build it for my system.
This software is a beast to build and package. On first compilation, it spent like ~5-6 hours just pulling Rust crates. This time thankfully was significantly reduced once the relevant packages were in cargo caché; only the changed/added ones were picked up.
But the second problem is even more annoying. Building Deno happily consumes about ~16-20 GB of precious disk space on space-constrained SSDs. This is too much.
I think we should go back to more efficient software, both in object code formats (the product) as well as in the build process. Why would a single JS runtime need 20 GB storage to be built? This is wasteful.
42 comments
[ 2.6 ms ] story [ 64.4 ms ] thread> The release post for v2.8 is not yet published.
> Check GitHub releases page for the latest release status of Deno.
The release is here: https://github.com/denoland/deno/releases/tag/v2.8.0
EDIT: Formatting
https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...
Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.
Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.
For those using Node.js, a similar single command is available with https://www.npmjs.com/package/ts-node-pack
Now that Node.js supports importing .ts modules, more repos can use them without a build step or putting any build artifacts in the checkout.
This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense.
I'm wondering how Deno would've been received if it supported npm and package.json from day 1.
If you're using node directly, please stop. At a minimum use Bun.
With agentic work, there is little reason to use anything besides Rust and Typescript in any case. Room to disagree but type safety, memory safety, and a large corpus of work is critical. Agents need difficult errors and baked in patterns they navigate it easily. For UI, Typescript makes the most sense just because of the mass of design examples.
I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?
Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.
Everything just came together at the right time really quickly and they managed to capitalize on it.
Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.
Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now.
Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice
Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.
Deno since adjusted, but Bun gained a lot of market share in the meantime.
And node / bun development is much easier because of many many npm packages.
Bundler + used by Claude Code, that’s pretty much it.
Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc.
Finally, Bun overall has better performance and efficiency compared to Deno.
That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.
https://tc39.es/proposal-type-annotations/
https://github.com/linus/testy
And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.
Well done Deno team.
In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.
What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.
It really is such a pleasure. It feels almost like a blend of JS and Go. Fast, flexible, slightly saner package management with more powerful capabilities than other JS/TS alternatives, a better security model, better standard library (so to speak)... And very fast. I love it.
The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.
If Deno continues this trajectory then there is less and less reason to use it over Node.
> The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.
Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.
While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.
Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.
Good work to everyone on the Deno team!
[1] https://edgejs.org/
Full time for the last three months.
Deno replaced a pnpm monorepo I was using.
This software is a beast to build and package. On first compilation, it spent like ~5-6 hours just pulling Rust crates. This time thankfully was significantly reduced once the relevant packages were in cargo caché; only the changed/added ones were picked up.
But the second problem is even more annoying. Building Deno happily consumes about ~16-20 GB of precious disk space on space-constrained SSDs. This is too much.
I think we should go back to more efficient software, both in object code formats (the product) as well as in the build process. Why would a single JS runtime need 20 GB storage to be built? This is wasteful.