DEV Community

Fernando Rodriguez
Fernando Rodriguez

Posted on • Originally published at frr.dev

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

#bunjs #javascript #typescript #node

The news nobody saw coming

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

Yes, the company behind Claude decided their future involves a JavaScript runtime written in Zig by a guy who thought "what if Node, but fast?" Claude Code just hit a billion dollars in revenue, and apparently the first thing you do when you have cash to spare is buy development tools.

Why? Because Claude Code executes JavaScript like there's no tomorrow, and every millisecond counts when you have millions of users. In other words: if your business depends on running code fast, you buy the fastest runtime.

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

What is Bun (for those coming from Node)

Bun is as if someone 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   → TypeScript execution
Enter fullscreen mode Exit fullscreen mode

Now you have:

bun           → all of the above
Enter fullscreen mode Exit fullscreen mode

It's the electric scooter versus the car with trailer. Fewer parts, fewer things that can break, and surprisingly 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
Transpiling TypeScript Need tools 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 the world's most important problem was that npm install took too long.

And, you know what, 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'll 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 just like Node.
  • TypeScript: Native, no configuration needed.
  • JSX: Also native.

Might cause issues

  • Packages with Node native bindings: Some need recompilation.
  • Code depending on specific V8 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 Bun project

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

curl -fsSL https://bun.sh/install | bash
Enter fullscreen mode Exit fullscreen mode

Or if you're on macOS with Homebrew:

brew install oven-sh/bun/bun
Enter fullscreen mode Exit fullscreen mode

Verify it works:

bun --version
Enter fullscreen mode Exit fullscreen mode

Creating a new project 

mkdir my-project && cd my-project
bun init
Enter fullscreen mode Exit fullscreen mode

This generates a package.json, tsconfig.json, and index.ts. No questions, no wizards. Just how I like it.

The file it generates 

// index.ts
console.log("Hello via Bun!");
Enter fullscreen mode Exit fullscreen mode

Run it:

bun run index.ts
Enter fullscreen mode Exit fullscreen mode

Yes, it executes TypeScript directly. No transpiling. No ts-node. No nothing.

Migrating from pnpm

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

# Option 1: Regenerate lockfile
rm -rf node_modules pnpm-lock.yaml
bun install

# Option 2: Use existing lockfile (experimental)
bun install
Enter fullscreen mode Exit fullscreen mode

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

The package.json doesn't change 

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "test": "vitest"
  }
}
Enter fullscreen mode Exit fullscreen mode

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

Tests: from Vitest to Bun

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

// sum.test.ts
import { expect, test } from "bun:test";
import { sum } from "./sum";

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

Run with:

bun test
Enter fullscreen mode Exit fullscreen mode

What if I want to keep using Vitest?

Works perfectly. Bun can run Vitest as a runtime:

bun run vitest
Enter fullscreen mode Exit fullscreen mode

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:

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

console.log("Server at http://localhost:3000");
Enter fullscreen mode Exit fullscreen mode

It uses the standard fetch API (Request/Response), so if you're coming from Cloudflare Workers or Deno, you'll feel right 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, that's not a typo.

Environment variables

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

# .env
DATABASE_URL=postgres://localhost/mydb
Enter fullscreen mode Exit fullscreen mode 
// index.ts
console.log(Bun.env.DATABASE_URL);
Enter fullscreen mode Exit fullscreen mode

That's it. Works, period.

Built-in SQLite

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

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);
Enter fullscreen mode Exit fullscreen mode

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

The bundler

Bun can also bundle your code for production:

bun build ./index.ts --outdir ./dist
Enter fullscreen mode Exit fullscreen mode

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 not everything is rainbows and unicorns:

  1. Critical production where you can't experiment: Bun is stable, but Node has 15 years of resolved bugs.

  2. Packages with very specific native bindings: Some need extra work.

  3. Windows as primary platform: Works, but first-class support is for macOS/Linux.

  4. 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

  1. CI/CD: Reduced install time saves real money. Seriously, do the math.

  2. Scripts and internal tools: Startup speed makes scripts feel instant.

  3. New projects without legacy: Starting with Bun is simpler than starting with Node + npm + tsx + vitest + ...

  4. Serverless/Edge: Less startup time = fewer cold starts = less latency = happier users.

  5. Now that Anthropic backs it: This isn't trivial. They have cash, incentives, and 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 production project, evaluate in CI/CD first. That's where you notice the difference most 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 likes living on the edge, put it in production and tell me how it goes. I don't dare yet, but I'm keeping my fingers crossed.

Resources

Conclusion

Bun is what happens when someone looks at the JavaScript ecosystem and decides we can do better. And the worrying part is... they're right.

Is this the end of Node? Probably not. Node won't disappear just 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'll 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. Works with most existing TypeScript projects. Try it in CI first, where you'll notice the difference most.

This article was originally written in Spanish and translated with the help of AI.

Top comments (0)