I switched my entire stack to Bun six months ago. Every server, every script, every test runner. Here’s what I learned.
The pitch
Bun is a JavaScript runtime that doesn’t pretend to be something else. It runs TypeScript natively — no build step, no ts-node, no tsx. You write .ts files and run them. That alone removed an entire layer of tooling from every project.
Startup time matters more than benchmarks suggest. When your dev loop is “save, run, check,” shaving 200ms off each cycle compounds into hours over a project. Bun starts fast enough that the script feels instant.
The gaps
I won’t pretend it’s perfect. Some npm packages assume Node internals that Bun doesn’t implement yet. The native node: modules are mostly covered, but edge cases surface when you least expect them.
The test runner is good but young. No built-in coverage reporter that matches c8 or istanbul. The assertion library is built-in and clean, but if your team lives in Jest’s ecosystem of matchers and mocks, migration has friction.
What stayed on Node
CI runners. GitHub Actions ships Node, not Bun. I could install Bun in CI — and I do for my own projects — but for open-source libraries where contributors expect npm test to just work, Node stays as the CI runtime.
Production containers that need absolute stability. Bun’s release cadence is fast, which is great for features but means I pin versions aggressively and test upgrades before rolling them out.
The verdict
For new projects, Bun is my default. The developer experience advantage is real and the performance gains are measurable. For existing Node projects, I migrate when there’s a natural reason — never for the sake of migration alone.
The runtime wars are good for everyone. Competition drives improvement. Bun pushed Node to ship native TypeScript support. That’s the best possible outcome.