Comment by Tiberium

Comment by Tiberium 18 hours ago

87 replies

View on Hacker News

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.

TheFlyingFish 18 hours ago

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.

Reply View 14 replies
  • satvikpendem 18 hours ago

    Deno does all that. Hell, yarn does too, or pnpm as the sibling mentioned.

    Reply View 1 reply
  • WorldMaker 16 hours ago

    Deno does that. It also refrains from keeping a local node_modules at all until/unless you explicitly ask it to for whatever compatibility reason. There are plugins to things like esbuild to use the Deno resolver and not need a node_modules at all (if you aren't also using the Deno-provided bundler for whatever reason such as it disappeared for a couple versions and is still marked "experimental").

    Reply View 0 replies
  • homebrewer 18 hours ago

    pnpm does all that on top of node. Also disables postinstall scripts by default, making the recent security incidents we've seen a non-issue.

    Reply View 6 replies
    • junon 16 hours ago

      As the victim of the larger pre-Shai-Hulud attack, unfortunately the install script validation wouldn't have protected you. Also, if you already have an infected package on the whitelist, a new infection in the install script will still affect you.

      Reply View 0 replies
    • daheza 17 hours ago

      Are there any popular packages that require postinstall scripts that this hurts?

      Reply View 0 replies
    • replete 13 hours ago

      A whitelist in package.json is only a partial assist

      Reply View 0 replies
  • agumonkey 17 hours ago

    IIRC bun zig code base has a lot of fine optimization too. I think the lead did a conference explaining his work. Or maybe i'm confused.

    Reply View 2 replies
  • user34283 13 hours ago

    I decided to stick with Node in general. I don't see any compelling reason to change it.

    Faster install and less disk space due to hardlink? Not really all that important to me. Npm comes with a cache too, and I have the disk space. I don't need it to be faster.

    With the old-school setup I can easily manually edit something in node_modules to quickly test a change.

    No more node_modules? It was a cool idea when yarn 2 initially implemented it, but at the end of the day I prefer things to just work rather than debug what is and isn't broken by the new resolver. At the time my DevOps team also wasn't too excited about me proposing to put the dependencies into git for the zero-install.

    Reply View 0 replies
satvikpendem 18 hours ago

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.

Reply View 12 replies
  • reactordev 17 hours ago

    This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state. Whether it be kernel exception, pointer exception, or Rust's panic! - these things exist.

    The reason why you see so many GitHub issues about it is because that's where the development is. Deno is great. Bun is great. These two things can both be great and we don't have to choose sides. Deno has it's use case. Bun has it's. Deno want's to be secure and require permissions. Bun just wants to make clean, simple, projects. This fight between Rust vs The World is getting old. Rust isn't any "safer" when Deno can panic too.

    Reply View 7 replies
    • satvikpendem 17 hours ago

      Don't make a false equivalence, how many times does one get a panic from Deno versus a segmentation fault in Bun? It's not a similar number, and it's simply wrong to say that both are just as unsafe when that's plainly untrue.

      Reply View 3 replies
      • ricardobeat 15 hours ago

        Anecodtally? Zero segfaults with bun since I started using it back in beta.

        Reply View 0 replies
      • reactordev 14 hours ago

        The only time I got a segfault in Bun is when I used bun:ffi to wrap glfw and wgpu-native so I can threejs on the desktop. Ironically, the segfault was in wgpu. Which is Rust. But to be fair it was because the glfw surface had dirty flags for OpenGL and didn’t have the Vulkan extensions. So anyone would have faulted.

        Reply View 0 replies
      • hu3 12 hours ago

        I use Bun in production. Well, one of my clients.

        We have yet to witness a segfault. Admitedly it's a bunch of micro services and not many requests/s (around 5k AVG).

        Reply View 0 replies
    • diarrhea 17 hours ago

      > This is a non sequitur. Both Rust and Zig and any other language has the ability to end in an exception state.

      There are degrees to this though. A panic + unwind in Rust is clean and _safe_, thus preferable to segfaults.

      Java and Go are another similar example. Only in the latter can races on multi-word data structures lead to "arbitrary memory corruption" [1]. Even in those GC languages there's degrees to memory safety.

      1: https://go.dev/ref/mem

      Reply View 1 reply
      • drannex 17 hours ago

        I'll take a small panic and unwind any day over a total burnout crash. Matters in code and life.

        Reply View 0 replies
    • skipants 17 hours ago

      I agree. Pointing at Github issues is a strange metric to me. If we want to use that as a canary then you shouldn't use Deno (2.4k open issues) or Bun (4.5k open issues) at all.

      Reply View 0 replies
  • rvrb 16 hours ago

    I haven't verified this, but I would be willing to bet that most of Bun's issues here have more to do with interfacing with JavaScriptCore through the C FFI than Zig itself. this is as much a problem in Rust as it is in Zig. in fact, it has been argued that writing unsafe Zig is safer than writing unsafe Rust: https://zackoverflow.dev/writing/unsafe-rust-vs-zig/

    Reply View 3 replies
    • polkchip2019 14 hours ago

      As someone who has researched the internals of Deno and Bun, your unverified vibe thoughts are flat out wrong. Bun is newer and buggier and that's just the way things go sometimes. You'll get over it.

      Reply View 0 replies
spiffytech 17 hours ago

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.

Reply View 1 reply
  • fastball 15 hours ago

    Which makes sense given that a big impetus for Deno's existence was the creator of Node/Deno (Ryan Dahl) wanting to correct things he viewed as design mistakes in Node.

    Reply View 0 replies
WorldMaker 16 hours ago

> 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.

Reply View 0 replies
kabirgoel 15 hours ago

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.

Reply View 0 replies
skybrian 18 hours ago

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/

Reply View 3 replies
  • Tiberium 17 hours ago

    It's interesting that people have directly opposite opinions on whether Deno or Bun are meant to be used with the existing ecosystem - https://news.ycombinator.com/item?id=46125049

    Reply View 1 reply
    • hardwaregeek 17 hours ago

      I don’t think these are mutually exclusive takes. Bun is essentially taking Node and giving it a standard library and standard tooling. But you can still use regular node packages if you want. Whereas Deno def leaned into the clean break for a while

      Reply View 0 replies
ecares 18 hours ago

It has wayyyyy better nodejs compatibility (day 1 goal)

Reply View 3 replies
  • Tiberium 18 hours ago

    As far as I know, modern Node compat in Deno is also quite great - I just import packages via 'npm:package' and they work, even install scripts work. Although I remember that in the past Deno's Node compat was worse, yes.

    Reply View 0 replies
  • 0x457 16 hours ago

    Pretty sure one of the Deno day 1 goals was to correct mistakes made during the early days of Node.js.

    Reply View 1 reply
    • [removed] 15 hours ago
      [deleted]
      Reply View 0 replies
kamikazechaser 6 hours ago

At this stage I don't think either is better over the other. Deno has inexplicable high memory usage issues in Linux containers. Bun more or less suffers from the same with an added dose of segfaults.

1. https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 2. https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

Node.js is a no-brainer for anyone shipping a TS/JS backend. I'd rather deal with poor DX and slightly worse performance than risk fighting runtime related issues on deployment.

Linux needs to be a first class citizen for any runtime/langauge toolchain.

Reply View 0 replies
bodge5000 14 hours ago

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

Reply View 0 replies
creata 14 hours ago

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.

Reply View 0 replies
gre 18 hours ago

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

Reply View 0 replies
bcye 17 hours ago

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)

Reply View 2 replies
  • catapart 17 hours ago

    Same. I had a little library I wrote to wrap indexedDB and deno wouldn't even compile it because it referenced those browser apis. I'm sure it's a simple flag or config file property, or x, or y, or z, but the simple fact is, bun didn't fail to compile.

    Between that and the discord, I have gotten the distinct impression that deno is for "server javascript" first, rather than just "javascript" first. Which is understandable, but not very catering to me, a frontend-first dev.

    Reply View 1 reply
    • bcye 17 hours ago

      Even for server ~~java~~typescript, I almost always reach for Bun nowadays. Used to be because of typestripping, which node now has too, but it's very convenient to write a quick script, import libraries and not have to worry about what format they are in.

      Reply View 0 replies
dunham 16 hours ago

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).

Reply View 0 replies
cesarvarela 18 hours ago

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

Reply View 9 replies
  • smarnach 17 hours ago

    Twice as fast at executing JavaScript? There's absolutely zero chance this is true. A JavaScript engine that's twice as fast as V8 in general doesn't exist. There may be 5 or 10 percent difference, but nothing really meaningful.

    Reply View 8 replies
    • johnfn 16 hours ago

      You might want to revise what you consider to be "absolutely zero chance". Bun has an insanely fast startup time, so it definitely can be true for small workloads. A classic example of this was on Bun's website for a while[1] - it was "Running 266 React SSR tests faster than Jest can print its version number".

      [1]: https://x.com/jarredsumner/status/1542824445810642946

      Reply View 2 replies
      • smarnach 9 hours ago

        I only claimed there is absolutely zero chance that Bun is twice as fast at executing general JavaScript as Deno. The example doesn't give any insight into the relative speeds of Bun and Deno, as fast as I can tell.

        Reply View 1 reply
        • johnfn 6 hours ago

              johnfn@mac ~ % time  deno eval 'console.log("hello world")'
    hello world
    deno eval 'console.log("hello world")'  0.04s user 0.02s system 87% cpu 0.074 total
    johnfn@mac ~ % time   bun -e 'console.log("hello world")'
    hello world
    bun -e 'console.log("hello world")'  0.01s user 0.00s system 84% cpu 0.013 total
          That's about 560% faster. Yes, it's a microbenchmark. But you said "absolutely zero chance", not "a very small chance".
          Reply View 0 replies
    • jasnell 15 hours ago

      Keep in mind that it's not just a matter of comparing the JS engine. The runtime that is built around the engine can have a far greater impact on performance than the choice of v8 vs. JSC vs. anything else. In many microbenchmarks, Bun routinely outperforms Node.js and Deno in most tasks by a wide margin.

      Reply View 2 replies
      • smarnach 9 hours ago

        The claim I responded to is that Bun is "at least twice as fast" as Deno. This sounds a lot more general than Bun being twice as fast in cherry-picked microbenchmarks. I wasn't able to find any benchmark that found meaningful differences between the two runtimes for real-world workloads. (Example: https://hackernoon.com/myth-vs-reality-real-world-runtime-pe...)

        Reply View 1 reply
        • Aeolun 8 hours ago

          Real world benchmarks include database queries and http requests? That’d quickly obviate any differences between runtimes.

          Lol, yeah, this person is running a performance test on postgres, and attributing the times to JS frameworks.

          Reply View 0 replies
    • ukblewis 16 hours ago

      It depends on what. Bun has some major optimisations. You’ll have to read into them if you don’t believe me. The graphs don’t come from nowhere

      Reply View 0 replies
    • [removed] 16 hours ago
      [deleted]
      Reply View 0 replies
pjmlp 17 hours ago

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.

Reply View 7 replies
  • defen 17 hours ago

    I find comments like this fascinating, because you're implicitly evaluating a counterfactual where Bun was built with Rust (or some other "interesting" language). Maybe Bun would be better if it were built in Rust. But maybe it would have been slower (either at runtime or development speed) and not gotten far enough along to be acquired by one of the hottest companies in the world. There's no way to know. Why did Anthropic choose Bun instead of Deno, if Deno is written in a better language?

    Reply View 6 replies
    • pjmlp 17 hours ago

      Because maybe they reached out to them, and they didn't took the money, while Bun folks business model wasn't working out?

      Who knows?

      Besides, how are they going to get back the money spent on the acquisition?

      Many times the answer to acquisitions has nothing to do with technology.

      Reply View 2 replies
      • defen 17 hours ago

        > Claude Code, FactoryAI, OpenCode, and others are all built with Bun.

        Anthropic chose to use Bun to build their tooling.

        Reply View 1 reply
        • pjmlp 16 hours ago

          We can think of they making bun an internal tool, push roadmap items that fit their internal products, whatever, which doesn't answer the getting back money of the acquisition.

          Profit in those products has to justify having now their own compiler team for a JavaScript runtime.

          Reply View 0 replies
    • Aeolun 8 hours ago

      > Why did Anthropic choose Bun instead of Deno, if Deno is written in a better language?

      Something about moral and philosophical flexibility.

      Reply View 0 replies
    • n42 15 hours ago

      Don't engage with this guy, he shows up in every one of these threads to pattern match back to his heyday without considering any of the nuance of what is actually different this time.

      Reply View 1 reply
gr4vityWall 18 hours ago

> 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.

Reply View 8 replies
  • Tiberium 18 hours ago

    Good question, hard to say, but I think it's mainly because of Zig. At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.

    Reply View 5 replies
    • AndyKelley 10 hours ago

      > At its core Zig is marketed as a competitor to C, not C++/Rust/etc

      What gives you this impression?

      I directly created Zig to replace C++. I used C++ before I wrote Zig. I wrote Zig originally in C++. I recently ported Chromaprint from C++ to Zig, with nice performance results. I constantly talk about how batching is superior to RAII.

      Everyone loves to parrot this "Zig is to C as Rust is to C++" nonsense. It's some kind of mind virus that spreads despite any factual basis.

      I don't mean to disparage you in particular, this is like the 1000th time I've seen this.

      Reply View 3 replies
      • troad 6 hours ago

        You have pretty explicitly framed Zig as a C replacement yourself, e.g.: https://www.youtube.com/watch?v=Gv2I7qTux7g

        More broadly, I think the observation tends to get repeated because C and Zig share a certain elegance and simplicity (even if C's elegance has dated). C++ is many things, but it's hardly elegant or simple.

        I don't think anyone denies that Zig can be a C++ replacement, but that's hardly unusual, so can many other languages (Rust, Swift, etc). What's noteworthy here is that Zig is almost unique in having the potential to be a genuine C replacement. To its (and your) great credit, I might add.

        >> At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.

        @GP: This is not a great take. All four languages are oriented around manual memory management. C++ inherits all of the footguns of C, whereas Zig and Rust try to sand off the rough edges.

        Manual memory management is and will always remain necessary. The only reason someone writing JS scripts don't need to worry about managing their memory is because someone has already done that work for them.

        Reply View 0 replies
      • [removed] 7 hours ago
        [deleted]
        Reply View 0 replies
      • Aeolun 8 hours ago

        I got to love that the author of the thing can show up and say “Why?! I never said any of that!”

        A lot of stuff related to older languages is lost in the sands of time, but the same thing isn’t true for current ones.

        Reply View 0 replies
    • ecshafer 17 hours ago

      Rust is more of a competitor to C++ than C. Manual memory management is sometimes really helpful and necessary. Zig has a lot of safety features.

      Reply View 0 replies
  • fn-mote 13 hours ago

    I mean, they said they looked at the source code and thought it was gross, so there’s a justification for their concern, at least.

    Reply View 1 reply
    • gr4vityWall 2 hours ago

      That's fair, but the word 'biased' felt unusual to describe how they perceive the runtime.

      Reply View 0 replies
kenhwang 18 hours ago

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.

Reply View 3 replies
  • skybrian 17 hours ago

    If you want to download open source libraries to be used in your Bun project then they will come from npm, at least by default. [1].

    So it seems odd to say that Bun is less dependent on the npm library ecosystem.

    [1] It’s possible to use jsr.io instead: https://jsr.io/docs/using-packages

    Reply View 2 replies
    • kenhwang 17 hours ago

      Yes, both can pull in open source libraries and I can't imagine either dropping that ability. Though they do seem to have different eagerness and competency on Node compatibility and Bun seems better on that front.

      From a long term design philosophy prospective, Bun seems to want to have a sufficiently large core and standard library where you won't need to pull in much from the outside. Code written for Node will run on Bun, but code using Bun specific features won't run on Node. It's the "embrace, extend, ..." approach.

      Deno seems much more focused on tooling instead of expanding core JS, and seems to draws the line at integrations. The philosophy seems to be more along the lines of having the tools be better about security when pulling in libraries instead of replacing the need for libraries. Deno also has it's own standard library, but it's just a library and that library can run on Node.

      Reply View 1 reply
silasdavis 17 hours ago

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

Reply View 2 replies
  • croes 17 hours ago

    Isn’t because packages are one of the problems deno tried to fix?

    Reply View 1 reply
    • WorldMaker 16 hours ago

      They tried to realign package management with web standards and tools that browsers can share (URLs and importmaps and "cache, don't install"). They didn't offer compatibility with existing package managers (notably and notoriously npm) until late in that game and took multiple swings at URL-based package repositories (deno.land/x/ and JSR), with JSR eventually realizing it needed stronger npm compatibility.

      Bun did prioritize npm compatibility earlier.

      Today though there seems to be a lot of parity, and I think things like JSR and strong importmaps support start to weigh in Deno's favor.

      Reply View 0 replies
dmit 17 hours ago

> 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.

Reply View 0 replies
torginus 16 hours ago

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.

Reply View 1 reply
  • hinkley 16 hours ago

    The speed shows up for large projects. Especially if you end up with multiple node_modules directories in your dev sandbox.

    Reply View 0 replies
yieldcrv 17 hours ago

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

Reply View 0 replies