Bun: Rethinking the JavaScript Runtime

I didn't think I needed another JavaScript runtime. Node works. It's boring in the good way — every tutorial, every host, every error message on the internet assumes it. So when Bun started getting loud a couple of years back, I shrugged. Another shiny tool that'd be dead in six months.

Then a friend made me actually try it. I've now migrated a real project onto it, and this is the part where I admit the shrug was wrong — with the caveats included, because it's not all sunshine.

Day one: the install that felt like a bug

bash
bun install

First run on a mid-size project: it finished before I finished reading the output. I genuinely ran it again because I assumed it had silently failed. Then I checked — everything was there, including the lockfile. Bun keeps a global module cache and uses a binary lockfile, so repeat installs are nearly free. That one experience reset my expectations for every other tool, and I haven't fully recovered.

The npm-compatible part matters more than the speed: I moved a Next.js project over without changing a single dependency. The lockfile format is different (bun.lockb), but Bun reads package-lock.json too, so the migration was just deleting node_modules and reinstalling.

What's actually under the hood

Bun is written in Zig, and it runs on JavaScriptCore — the engine inside Safari — instead of V8. Those two choices explain most of what feels different: JavaScriptCore has different performance characteristics, especially for cold starts, and Zig gives the runtime a small, fast core that doesn't carry twenty years of Node baggage.

It's also an all-in-one tool. One binary replaces Node, npm/pnpm/yarn, a bundler, and a test runner:

bash
bun run index.ts        # run TypeScript directly, no tsconfig dance
bun build src/index.ts --outdir dist
bun test

No webpack config, no separate TypeScript step, no stitching five tools together just to run a file. The cognitive overhead that just vanishes is the part that's hard to explain until you've felt it.

A server is six lines:

ts
Bun.serve({
  port: 3000,
  fetch() {
    return new Response("Hello from Bun ⚡");
  },
});

No Express, no middleware stack, no dependencies. It starts in single-digit milliseconds.

Where it bit me

I'd be lying if I said it was seamless. Two things have actually annoyed me:

Node API gaps. Most of the surface is compatible, but some Node APIs are still partial or missing edge behavior. My main app worked on the first try; a second project with an older library didn't, and I had to dig into issues to confirm it was a Bun problem, not mine.

The ecosystem is younger. Fewer people have hit the weird edge cases, which means when something breaks, the Stack Overflow answer might still be "haven't seen this yet." That's getting rarer month by month, but it's real.

For new projects, though — especially TypeScript-first, modern-stack stuff — I genuinely can't think of a reason to start with Node anymore. Bun runs the same code, faster, with less setup. The compatibility gaps mostly belong to legacy Node apps that I'm not starting anyway.

Why I care beyond the speed

I study security, which means I think about attack surface and bloat the way other people think about their fantasy football team. Bun appeals to that instinct directly: fewer tools means fewer things to audit and fewer supply-chain entry points; a smaller runtime footprint means less code running with your permissions. The security argument isn't why I switched, but it's why the switch feels right rather than just fast.

If you're starting something new and you haven't tried it: bun init, paste in one of your existing projects, and watch the install finish. I was wrong about Bun being a flash in the pan — and I'm happy to be wrong when the tool earns it.