As someone who have been using Deno for the last few years, is there anything that Bun does better? Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?). The last time I checked Bun's source code, it was... quite messy and spaghetti-like, plus Zig doesn't really offer many safety features, so it's not that hard to write incorrect code. Zig does force some safety with ReleaseSafe IIRC, but it's still not the same as even modern C++, let alone Rust.

I'll admit I'm somewhat biased against Bun, but I'm honestly interested in knowing why people prefer Bun over Deno.

I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage.

Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience.

I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not?

As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.

Search for pointer exceptions or core dumps on Bun's GitHub issues and you'll see why people (should) use Deno over Bun, if only because Rust is a way more safe language than Zig.

Easily bundling and serving frontend code from your backend code is very appealing: https://bun.com/docs/bundler/fullstack

Despite the page title being "Fullstack dev server", it's also useful in production (Ctrl-F "Production Mode").

I really want to like Deno and will likely try it again, but last time I did it was just a bit of a pain anytime I wanted to use something built for npm (which is most packages out there), whereas bun didn't have that problem.

There's certainly an argument to be made that, like any good tool, you have to learn Deno and can't fall back on just reusing node knowledge, and I'd absolutely agree with that, but in that case I wanted to learn the package, not the package manager.

Edit: Also it has a nice standard library, not a huge win because that stuff is also doable in Deno, but again, its just a bit less painless

Looking at Bun's website (the comparison table under "What's different about Bun?") and what people have said here, the only significant benefit of Bun over Node.js seems to be that it's more batteries-included - a bigger standard library, more tools, some convenience features like compiling JSX and stripping TypeScript types on-the-fly, etc.

It's not clear to me why that requires creating a whole new runtime, or why they made the decisions they did, like choosing JSC instead of V8, or using a pre-1.0 language like Zig.

My team has been using it in prod for about a year now. There were some minor bugs in the runtime's implementation of buffers in 1.22 (?), but that was about the only issue we ran into.

The nice things:

1. It's fast.

2. The standard library is great. (This may be less of an advantage over Deno.)

3. There's a ton of momentum behind it.

4. It's closer to Node.js than Deno is, at least last I tried. There were a bunch of little Node <> Deno papercuts. For example, Deno wanted .ts extensions on all imports.

5. I don't have to think about JSR.

The warts:

1. The package manager has some issues that make it hard for us to use. I've forgotten why now, but this in particular bit us in the ass: https://github.com/oven-sh/bun/issues/6608. We use PNPM and are very happy with it, even if it's not as fast as Bun's package manager.

Overall, Deno felt to me like they were building a parallel ecosystem that I don't have a ton of conviction in, while Bun feels focused on meeting me where I am.

I tried several times to port Node projects to Deno. Each time compatibility had "improved" but I still didn't have a working build after a few days of effort.

I don't know how Deno is today. I switched to Bun and porting went a lot smoother.

Philosophically, I like that Bun sees Node compatibility as an obvious top priority. Deno sees it as a grudging necessity after losing the fight to do things differently.

> Bun seems to use a different runtime (JSC) which is less tested than V8, which makes me assume it might perform worse in real-world tasks (maybe not anymore?).

JSC is still the JS engine for WebKit-based browsers, especially Safari, and per Apple App Store regulations the only JS engine supposedly allowable in all of iOS.

It's more "mature" than V8 in terms of predating it. (V8 was not a fork of it and was started from scratch, but V8 was designed to replace it in the Blink fork from WebKit.)

It has different performance goals and performance characteristics, but "less tested" seems uncharitable and it is certainly used in plenty of "real-world tasks" daily in iOS and macOS.

I’ve been using Deno too. Although npm support has improved and it’s fine for me, I think Deno has more of a “rewrite the world” philosophy. For example, they created their own package registry [1] and their own web framework [2]. Bun seems much more focused on preexisting JavaScript projects.

[1] https://jsr.io/ [2] https://fresh.deno.dev/

It has wayyyyy better nodejs compatibility (day 1 goal)

I had memory leaks in bun and not in deno or node for the same code. ymmv

Is JSC less tested? I thought it was used in Safari, which has some market share.

I used bun briefly to run the output of my compiler, because it was the only javascript runtime that did tail calls. But I eventually added a tail call transform to my compiler and switched to node, which runs 40% faster for my test case (the compiler building itself).

It just works. Whatever JavaScript/TypeScript file or dependencies I throw at it, it will run it without needing to figure out CJS or ESM, tsconfig, etc.

I haven't had that experience with deno (or node)

Agreed, the language would be interesting during the 1990's, nowadays not so much.

The tools that the language offers to handle use after free is hardly any different from using Purify, Insure++ back in 2000.

I've found it to be at least twice as fast with practically no compat issues.

> I'll admit I'm somewhat biased against Bun?

Why? Genuine question, sorry if it was said/implied in your original message and I missed it.

I always figured Bun was the "enterprise software" choice, where you'd want to use Bun tools and libraries for everything and not need to bring in much from the broader NPM library ecosystem.

Deno seems like the better replacement for Node, but it'd still be at risk of NPM supply chain attacks which seems to be the greater concern for companies these days.

Stopped following Deno while they were rejecting the need for a package management solution. Used Bun instead.

Is it just me, but I don't find npm that slow? Sure it's not a speed demon, but I rarely need to do npm install anyways so it's not a bottleneck for me.

For deploy, usually running the attached terraform script takes more time.

So while a speed increase is welcome, but I don't feel it gives me such a boost.

> is there anything that Bun does better?

Telling prospective employees that if you're not ready to work 60-hour weeks, then what the fuck are you doing here? for one.

> Zig does force some safety with ReleaseSafe IIRC

which Bun doesn't use, choosing to go with `ReleaseFast` instead.

I've been using Bun since 2022 just to be trendy for recruitment (it worked, and still works despite it almost being 2026)

Bun is fast, and its worked as a drop in replacement for npm in large legacy projects too.

I only ever encountered one issue, which was pretty dumb, Amazon's CDK has hardcoded references to various package manager's lock files, and Bun wasn't one of them

https://github.com/aws/aws-cdk/issues/31753

This wasn't fixed till the end of 2024 and as you can see, only accidentally merged in but tolerated. It was promptly broken by a bun breaking change

https://github.com/aws/aws-cdk/issues/33464

but don't let Amazon's own incompetency be the confirmation bias you were looking for about using a different package manager in production

you can use SST to deploy cloud resources on AWS and any cloud, and that package works with bun