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.
> Can someone explain why it sounds like there's such rapid growth of Bun?
In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.
So, I switched to Bun and things have been much smoother!
I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works.
Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.
Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.
A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).
So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.
I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.
Edit: And Deno is now more compatible with node than bun.
I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.
(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.
because for most people they don't need what deno promises.
me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).
bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.
When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.
But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.
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`.
I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.
> It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.
Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.
(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)
Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.
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.
For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.
Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.
Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.
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?
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
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.
I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.
I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)
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.
> Can someone explain why it sounds like there's such rapid growth of Bun?
In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.
I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.
So, I switched to Bun and things have been much smoother!
I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.
But if you look at the node compliance tests, deno has better compliance now days…
Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.
A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).
So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.
I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.
Edit: And Deno is now more compatible with node than bun.
(thinking emoji) they could merge.
Seriously, they're both Rust now. They share goals.
> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.
and yet Bun's npm compat is much much lower than deno
https://x.com/rough__sea/status/2057579066744881188
I was talking about the history and not the current state of the projects if that was not obvious.
I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.
(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)
I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.
because for most people they don't need what deno promises.
me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).
bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.
too bad it is a failed promise now.
When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.
But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.
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`.
They did lay off ~half the company ~2 months ago: https://news.ycombinator.com/item?id=47467746
You can already ship single executables, my product's CLI is a Node single executable application
It's good to have some options, to prevent the ecosystem from stalling
I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.
> 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.
> It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.
I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.
Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.
(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)
Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.
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.
> safer bet as a dependency.
The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.
That was Bun at Anthropic, not uv at OpenAI.
Is this a joke I'm not getting or are your wires crossed? Bun is the topic of this subthread.
running out of money, for an open source project of almost any kind, is safer than "running into money" with the wrong strings attached
(still reserving judgement on Bun, though — I mean, we'll soon see, one way or the other!)
> which makes them a safer bet as a dependency
Wouldn't node be the safest bet as a dependency?
For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.
Exactly.
https://github.com/yt-dlp/yt-dlp/issues/16766
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.
Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.
Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.
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
I don't get it why the hell is TypeScript still not nativly supported in modern browsers?
Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?
Likely because everybody would still strip types, bundle and minify their typescript code anyway. Nobody would use this.
JS promise to never break the web. can't say the same about TS
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.
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.
https://deno.com/blog/v2.8
> 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.
I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.
I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)
As someone that works in projects with standard IT tools, not supporting NPM made it a non starter for us.
No way it would go through standard build pipelines, or team skills.
"standard" IT tools?