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`.
Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition.
Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.
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 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:
It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?
Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?
I wonder how Deno's faring.
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`.
> and, soon enough, you'll be able to build your app to a single executable -- including native deps.
Whoa, did not know that. That's a killer feature!
> Plus, bought by Anthropic.
Who thinks this is a positive?!
That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.
It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
> safer bet as a dependency.
The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.
Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition.
Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.
They did lay off ~half the company ~2 months ago: https://news.ycombinator.com/item?id=47467746
It's good to have some options, to prevent the ecosystem from stalling
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.
The new *deno pack* command is a nice addition for safe and simple packaging.
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.
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:
https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...
It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?
Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?
> The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?
As someone who has optimized by reducing/batching heap allocations, 2x seems within the realm of possibility, depending on the exact circumstances.
That being said, iirc, node also has more hooks for things like observability than bun does, which might hurt it here
> Deno now defaults to npm:
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.
By the time I read this, the blog post doesn't exist yet:
> 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
The release post for v2.8 is not yet published. Check GitHub releases page for the latest release status of Deno.