Home

Why I choose Bun for my projects, for now

August 3, 2026

For most of my career "JavaScript runtime" meant Node, full stop. That stopped being true a while ago. Deno and Bun are both stable, both used in production somewhere, and both worth an honest look instead of a reflex "Node just works." This is where I landed after actually running Bun on my own side projects for a while: I like it, I'm keeping it, and I'm not calling it permanent.

What actually made me switch

It wasn't a benchmark. It was bun install.

The first time I ran it on a project with a few hundred dependencies, I assumed something had failed silently because it finished before I'd read the output. No node_modules progress bar to stare at, no coffee break. That single, boring, repeated-dozens-of-times-a-day interaction is what made the difference for me, not a single flashy number.

Everything else followed from there:

sh
1bun init
2bun add hono zod
3bun run dev      # runs .ts directly, no ts-node, no build step
4bun test         # Jest-compatible API, no separate runner to install

One binary is the runtime, the package manager, the bundler, and the test runner. No tsconfig gymnastics to run a script, no jest.config to get a test suite going, no separate watcher. For a personal project I'm poking at in short bursts, every one of those is friction I used to just accept as the cost of doing JavaScript.

What I'm not claiming

I'm deliberately not repeating throughput numbers here. Every runtime's team publishes benchmarks that make their own runtime look best, measured on a workload they picked. That's true of Bun's marketing as much as anyone else's, and I have no independent way to verify the specific figures floating around comparison posts. What I can vouch for, because I've felt it directly:

  • Install and startup are consistently fast. Not "4x" fast in some universal sense, but fast enough that I stopped thinking about it.
  • TypeScript runs with zero setup. bun run script.ts just works — full syntax, no flags, no stripped-down subset.
  • The built-in test runner and bundler are genuinely usable, not toy versions you'll outgrow immediately.

Node.js has closed a lot of this gap on its own. node:test is stable, --watch replaces nodemon for most cases, and recent Node versions can execute TypeScript directly via type stripping — though only for "erasable" syntax; enum and namespace still need an experimental flag, and type stripping doesn't do actual type checking (keep tsc --noEmit in CI regardless of runtime). Node's permission model is also real, and it's something Bun doesn't have an equivalent for: Bun runs with full trust, no sandboxing, so anything your dependencies can do, they can do unrestricted.

Where I still don't reach for Bun

Deno's pitch is worth taking seriously precisely because it's different from Bun's: deny-by-default permissions. A Deno script can't touch the filesystem, network, or environment variables unless you explicitly grant it. That's a structurally different security posture than either Node or Bun offer, and for anything handling secrets or third-party code I don't fully trust, it's the one I'd reach for instead.

And for this portfolio specifically, I'm not touching anything — it stays on pnpm and Node, per the project's own conventions. Bun is where I run new personal tools, scripts, and small services I'm building from scratch, not where I migrate something that already works.

The actual decision process

The only test that matters is your own dependency tree and your own workload, not a chart. What I actually do before adopting Bun on something new:

  1. Install the real package.json and run the test suite. If a dependency leans on a native addon Bun doesn't support cleanly, I find out in minutes, not mid-project.
  2. Check where it needs to run. Bun's hosting support keeps growing, but it isn't Node's "supported literally everywhere." I confirm the target platform before writing a line of code.
  3. Accept that this can change. If I hit a wall — a package that won't cooperate, an observability tool that only instruments Node, a project that needs Deno's sandboxing more than Bun's speed — I'll use whichever runtime the project actually needs. Nothing here is a rule, it's a default.

Conclusion

Bun wins my day-to-day right now because the friction it removes is the friction I hit constantly: installs, TypeScript, running a test. That's not the same as saying it's objectively the best runtime, or that it will still be my default in a year. For now, on my own projects, it's the one that gets out of my way — and that's the whole bar it had to clear.

Docs: Bun · Node.js · Deno