I am being sincere and a little self deprecating when I say: because I prefer Gen X-coded projects (Node, and Deno for that matter) to Gen Z-coded projects (Bun).
Bun being VC-backed allows me to fig-leaf that emotional preference with a rational facade.
I think I kind of get you, there's something I find off putting about Bun like it's a trendy ORM or front end framework where Node and Deno are trying to be the boring infrastructure a runtime should be.
Not to say Deno doesn't try, some of their marketing feels very "how do you do fellow kids" like they're trying to play the JS hype game but don't know how to.
Yes, that's it. I don't want a cute runtime, I want a boring and reliable one.
Deno has a cute mascot, but everything else about it says "trust me, I'm not exciting". Ryan Dahl himself also brings an "I've done his before" pedigree.
Because Bun is still far less mature (and the stack on which it builds is even less so - Zig isn't even 1.0).
Because its Node.js compat isn't perfect, and so if you're running on Node in prod for whatever reason (e.g. because it's an Electron app), you might want to use the same thing in dev to avoid "why doesn't it work??" head scratches.
Because Bun doesn't have as good IDE integration as Node does.
I haven't used it for a few months but in my experience, its package/monorepo management features suck compared to pnpm (dependencies leak between monorepo packages, the command line is buggy, etc), bun --bun is stupid, build scripts for packages routinely blow up since they use node so i end up needing to have both node and bun present for installs to work, packages routinely crash because they're not bun-compatible, most of the useful optimizations are making it into Node anyway, and installing ramda or whatever takes 2 seconds and I trust it so all of Bun's random helper libraries are of marginal utility.
We’ve made a lot of progress on bun install over the last few months:
- isolated, pnpm-style symlink installs for node_modules
- catalogs
- yarn.lock support (later today)
- bun audit
- bun update —interactive
- bun why <pkg> helps find why a package is installed
- bun info <pkg>
- bun pm pkg get
- bun pm version (for bumping)
We will also support pnpm lockfile migration next week. To do that, we’re writing a YAML parser. This will also unlock importing YAML files in JavaScript at runtime.
because bun is written in a language that isn't even stable (zig) and uses webkit. None of the developer niceties will cover that up. I also don't know if they'll be able to monetize, which means it might die if funding dries up.
I am being sincere and a little self deprecating when I say: because I prefer Gen X-coded projects (Node, and Deno for that matter) to Gen Z-coded projects (Bun).
Bun being VC-backed allows me to fig-leaf that emotional preference with a rational facade.
I think I kind of get you, there's something I find off putting about Bun like it's a trendy ORM or front end framework where Node and Deno are trying to be the boring infrastructure a runtime should be.
Not to say Deno doesn't try, some of their marketing feels very "how do you do fellow kids" like they're trying to play the JS hype game but don't know how to.
Yes, that's it. I don't want a cute runtime, I want a boring and reliable one.
Deno has a cute mascot, but everything else about it says "trust me, I'm not exciting". Ryan Dahl himself also brings an "I've done his before" pedigree.
Because Bun is still far less mature (and the stack on which it builds is even less so - Zig isn't even 1.0).
Because its Node.js compat isn't perfect, and so if you're running on Node in prod for whatever reason (e.g. because it's an Electron app), you might want to use the same thing in dev to avoid "why doesn't it work??" head scratches.
Because Bun doesn't have as good IDE integration as Node does.
I haven't used it for a few months but in my experience, its package/monorepo management features suck compared to pnpm (dependencies leak between monorepo packages, the command line is buggy, etc), bun --bun is stupid, build scripts for packages routinely blow up since they use node so i end up needing to have both node and bun present for installs to work, packages routinely crash because they're not bun-compatible, most of the useful optimizations are making it into Node anyway, and installing ramda or whatever takes 2 seconds and I trust it so all of Bun's random helper libraries are of marginal utility.
We’ve made a lot of progress on bun install over the last few months:
- isolated, pnpm-style symlink installs for node_modules
- catalogs
- yarn.lock support (later today)
- bun audit
- bun update —interactive
- bun why <pkg> helps find why a package is installed
- bun info <pkg>
- bun pm pkg get
- bun pm version (for bumping)
We will also support pnpm lockfile migration next week. To do that, we’re writing a YAML parser. This will also unlock importing YAML files in JavaScript at runtime.
Why bother with bun when deno 2 is a much better alternative for new projects?
Why bother with deno 2 when node 22 is a much better alternative for new projects?
(closing the circle)
because bun is written in a language that isn't even stable (zig) and uses webkit. None of the developer niceties will cover that up. I also don't know if they'll be able to monetize, which means it might die if funding dries up.
[dead]