Bun: The Runtime That Wants to Retire Node (and Now Has the Cash to Do It)

The news nobody saw coming

Last week, while you and I were peacefully wrestling with node_modules, Anthropic dropped a bomb: they’ve bought Bun.

Yes, the company behind Claude has decided that their future depends on a JavaScript runtime written in Zig by a guy who thought “what if Node, but fast?”. Claude Code just hit one billion dollars in revenue, and apparently the first thing you do when you have money to burn is buy development tools.

Why? Because Claude Code executes JavaScript like crazy, and every millisecond counts when you have millions of users. In plain English: if your business depends on running code fast, you buy the fastest runtime.

But enough corporate gossip. Let’s get to what interests you: what is Bun and why should you care.

What is Bun (for those of us coming from Node)

Bun is as if someone had looked at the Node ecosystem and said: “What if instead of having fifteen tools we make one that replaces them all?”

Where before you had:

node          → runtime
npm/pnpm/yarn → package manager
webpack/esbuild/vite → bundler
jest/vitest   → test runner
ts-node/tsx   → run TypeScript

Now you have:

bun           → all of the above

It’s the electric scooter vs. the car with trailer. Fewer parts, fewer things that can break, and curiously faster.

The numbers that matter

I don’t like doing benchmarks because they can always be manipulated. But these numbers are so brutal they’re worth mentioning:

Operation	Node + pnpm	Bun	Difference
`install` (medium project)	~25s	~3s	8x faster
Runtime startup	~50ms	~5ms	10x faster
Running tests	baseline	2-3x faster	Notable
Transpile TypeScript	Need tool	Native	∞

Why is it so fast? Because it’s written in Zig instead of C++, and because Jarred Sumner (the creator) is one of those programmers who optimizes code as a hobby. The guy worked at Stripe and decided that the most important problem in the world was that npm install took too long.

And, hey, maybe he was right.

What already works (and what doesn’t)

Bun is compatible with most Node APIs. If your code uses fs, path, http, or any standard module, it will probably work without changes.

Works well

Next.js: Official support. bun run dev and you’re done.
Express/Fastify: No problems.
Most npm packages: Bun reads package.json and node_modules the same as Node.
TypeScript: Native, no configuration.
JSX: Also native.

May cause problems

Packages with Node native bindings: Some need recompilation.
Code that depends on V8-specific quirks: Bun uses JavaScriptCore (Safari’s engine).
Some very specific Node APIs: Workers, some parts of cluster.

Doesn’t work (yet)

Windows: Works, but with some limitations.
Yarn PnP: Not supported.

Your first project with Bun

If you already have Node, installing Bun is one command:

1
curl -fsSL https://bun.sh/install | bash

Or if you’re on macOS and use Homebrew:

1
brew install oven-sh/bun/bun

Verify it works:

1
bun --version

Create a new project

1
2
mkdir my-project && cd my-project
bun init

This generates a package.json, a tsconfig.json, and an index.ts. No questions, no wizards. That’s how I like it.

The file it generates

1
2
// index.ts
console.log("Hello via Bun!");

Run it:

1
bun run index.ts

Yes, it runs TypeScript directly. No transpiling. No ts-node. Nothing.

Migrating from pnpm

If you have a project with pnpm, the migration is surprisingly straightforward:

1
2
3
4
5
6
# Option 1: Regenerate lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

# Option 2: Use existing lockfile (experimental)
bun install

Bun generates its own bun.lockb (binary, faster to parse). You can keep both lockfiles during the transition if you work in a team and not everyone has migrated.

The package.json doesn’t change

1
2
3
4
5
6
7
{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "test": "vitest"
  }
}

You still run bun run dev, bun run build, bun run test. The scripts work the same.

Tests: from Vitest to Bun

Bun has its own test runner that’s compatible with the Jest/Vitest API:

1
2
3
4
5
6
7
// sum.test.ts
import { expect, test } from "bun:test";
import { sum } from "./sum";

test("2 + 2 = 4", () => {
  expect(sum(2, 2)).toBe(4);
});

Run with:

1
bun test

What if I want to keep using Vitest?

It works perfectly. Bun can run Vitest as runtime:

1
bun run vitest

You get Bun’s startup speed with Vitest’s features. Best of both worlds.

The fastest HTTP server you’ll see

Bun includes an HTTP server that leaves Express crying in a corner:

1
2
3
4
5
6
7
8
Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun!");
  },
});

console.log("Server at http://localhost:3000");

It uses the standard fetch API (Request/Response), so if you come from Cloudflare Workers or Deno, you’ll feel at home.

Hello world benchmark

On my machine (M1 Pro), a hello world server:

Express: ~15,000 req/s
Fastify: ~45,000 req/s
Bun.serve: ~150,000 req/s

Yes, ten times faster than Express. No, it’s not a typo.

Environment variables

Bun loads .env automatically. No dotenv. No configuration.

1
2
# .env
DATABASE_URL=postgres://localhost/mydb

1
2
// index.ts
console.log(Bun.env.DATABASE_URL);

That’s it. It works, period.

Built-in SQLite

This blew my mind. Bun comes with SQLite built-in:

1
2
3
4
5
6
7
8
import { Database } from "bun:sqlite";

const db = new Database("mydb.sqlite");
db.run("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");
db.run("INSERT INTO users (name) VALUES (?)", ["Fernando"]);

const users = db.query("SELECT * FROM users").all();
console.log(users);

No installing better-sqlite3 or sql.js. It just works.

The bundler

Bun can also bundle your code for production:

1
bun build ./index.ts --outdir ./dist

It’s faster than esbuild (which was already ridiculously fast). For most projects, it generates equivalent bundles.

If you need something more sophisticated (code splitting, advanced tree shaking), you’ll probably still need Vite or webpack. But for many cases, this is enough.

When NOT to use Bun

Because it’s not all rainbows and unicorns:

Critical production where you can’t experiment: Bun is stable, but Node has 15 years of resolved bugs.
Packages with very specific native bindings: Some need extra work.
Windows as primary platform: It works, but first-class support is for macOS/Linux.
Your team doesn’t want to learn anything new: Sometimes the best tool is the one everyone knows how to use.

When to USE Bun

CI/CD: Reduced install time saves real money. Seriously, do the math.
Scripts and internal tools: The startup speed makes scripts feel instant.
New projects without legacy: Starting with Bun is simpler than starting with Node + npm + tsx + vitest + …
Serverless/Edge: Less startup time = fewer cold starts = less latency = happier users.
Now that Anthropic backs it: This is no small thing. They have money, they have incentives, and they have a product (Claude Code) that depends on Bun being good.

My recommendation

If you’re starting a new project and don’t have team constraints, try Bun. The worst that can happen is you go back to Node, and you’ll have learned something.

If you have an existing project in production, evaluate first in CI/CD. That’s where the difference is most noticeable and where there’s least risk. If bun install works well with your dependencies, you’ve already won.

And if you’re one of those who like living on the edge, put it in production and tell me how it goes. I don’t dare yet, but I have my fingers crossed.

Resources

Conclusion

Bun is what happens when someone looks at the JavaScript ecosystem and decides we can do better. And the scary thing is that… they’re right.

Is it the end of Node? Probably not. Node isn’t going to disappear like Java didn’t disappear when… well, anything came out. But it is the first serious competitor in a long time.

And now that Anthropic is behind it, with their billion dollars and their need for JavaScript to fly, things get interesting.

Meanwhile, I’m going to keep using pnpm in production. But my local scripts already run with Bun, and my CI is in the process of migration. Little by little.

TL;DR: Bun is an all-in-one JavaScript runtime (runtime + package manager + bundler + test runner) that’s significantly faster than Node. Anthropic just bought it. It works with most existing TypeScript projects. Try it in CI first, that’s where you notice it most.

The news nobody saw coming#

What is Bun (for those of us coming from Node)#

The numbers that matter#

What already works (and what doesn’t)#

Works well#

May cause problems#

Doesn’t work (yet)#

Your first project with Bun#

Create a new project#

The file it generates#

Migrating from pnpm#

The package.json doesn’t change#

Tests: from Vitest to Bun#

What if I want to keep using Vitest?#

The fastest HTTP server you’ll see#

Hello world benchmark#

Environment variables#

Built-in SQLite#

The bundler#

When NOT to use Bun#

When to USE Bun#

My recommendation#

Resources#

Conclusion#