Bun Is Taking Over JavaScript (Here's How to Start)

BunJavaScriptDeveloper ToolsTrend CommentaryNode.js

April 3, 2026

Cover image for Bun Is Taking Over JavaScript (Here's How to Start)

Bun replaces Node.js, npm, Jest, and your TypeScript compiler with a single binary. After Anthropic acquired the runtime in December 2025, it now powers Claude Code and reaches millions of developers daily.

The Bun JavaScript runtime benchmarks are real but nuanced. Here's the honest performance story and a 5-minute getting-started tutorial.

The Anthropic Acquisition Changed Everything#

In December 2025, Anthropic acquired Bun. The runtime had raised $26M in venture capital but generated zero revenue.

Jarred Sumner's original plan was a hosting platform that never shipped. The VC-funded runtime was running on borrowed time, and everyone in the JS community knew it.

Anthropic buying Bun wasn't charity. They needed a fast, lightweight runtime for Claude Code, their AI coding agent, and Bun fit that need exactly.

Now Bun powers Claude Code's native installer, the Claude Agent SDK, and the growing ecosystem of AI coding agents built on Anthropic's stack. A Claude Code bot is currently the GitHub user with the most merged PRs in Bun's repository. That tells you where the investment is going.

Bun stays MIT-licensed and open-source. The current version is v1.3.11 (March 2026), with monthly releases shipping faster than at any point in the project's history.

Futuristic control room with terminal screens and a central bright orb connecting them
Futuristic control room with terminal screens and a central bright orb connecting them

Bun Performance: The Honest Numbers#

I need to lead with the caveat before the big numbers, because the benchmarks are misleading without it.

Synthetic benchmarks show Bun handling 52,000 HTTP requests per second versus Node.js at 14,000 (both using Express-style routing). Cold starts clock in at 8-15ms versus Node's 40-120ms.

Package installs are where things get absurd: installing React takes 2 seconds on Bun, 18 on npm. A monorepo with 1,847 dependencies installs in 47 seconds instead of 28 minutes.

Those numbers are real. But here's what matters for production: once you put a database behind your endpoints, throughput across runtimes converges hard. Your bottleneck becomes PostgreSQL, not your JavaScript engine.

Bun vs Node.js Performance
Each row scaled independently — bar lengths compare within a row, not across rows.
BunNode.js
HTTP req/s52000
14000
Cold Start (ms)12
80
Install (sec)2
18
Lambda Cold (ms)156
245

Where Bun's speed actually changes your workflow is developer experience. Faster installs, instant TypeScript execution, and sub-15ms starts on AWS Lambda (156ms versus 245ms) add up across a team of ten over six months.

Why Developers Are Switching#

The killer feature isn't raw speed. It's replacing five or six separate tools with one binary.

Bun replaces your entire JavaScript toolchain in one binary:

  • Runtime (replaces Node.js)
  • Package manager (replaces npm/yarn/pnpm)
  • Bundler (replaces webpack/esbuild)
  • Test runner (replaces Jest/Vitest)
  • TypeScript compiler (replaces ts-node/tsc)

You install one thing. It runs your .ts files, your tests, and your builds. The mental overhead drops to near zero.

Figma, The New York Times, and Slack run Bun in production. Tailwind CSS adopted it for their build tooling. The runtime now has over 7M monthly downloads.

Compatibility is the reason adoption works at all. Bun implements 95-98% of the Node.js API surface, and most existing code runs without changes.

You bun install your dependencies, bun run your scripts, and things work. I migrated a Next.js API project in under ten minutes with zero code changes.

Getting Started With Bun#

Install Bun with one command. On macOS and Linux:

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

On Windows (PowerShell):

terminal
irm bun.sh/install.ps1 | iex

Verify it works:

terminal
bun --version
# 1.3.11

Create a new project:

terminal
bun init
# Creates package.json, tsconfig.json, index.ts

Here's a complete HTTP server using Bun.serve():

Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
    if (url.pathname === "/api/health") {
      return Response.json({ status: "ok", runtime: "bun" });
    }
    return new Response("Hello from Bun!");
  },
});

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

Run it with hot reload:

terminal
bun --watch index.ts

No ts-node, no nodemon, no tsconfig fiddling. It just runs.

For a production-grade API, pair Bun with Hono, the lightweight framework built for edge runtimes:

index.ts
import { Hono } from "hono";

const app = new Hono();

app.get("/", (c) => c.json({ message: "Hono + Bun" }));
app.get("/users/:id", (c) => {
  return c.json({ id: c.req.param("id") });
});

export default app;

Testing is built in too. No Jest, no Vitest, no config files:

app.test.ts
import { expect, test, describe } from "bun:test";

describe("math", () => {
  test("adds numbers", () => {
    expect(2 + 2).toBe(4);
  });
});
terminal
bun test

If you use CLI tools in your daily workflow, Bun's single-binary approach will feel familiar. One tool, many jobs.

Clean desk with one glowing tool replacing a pile of old dev tools
Clean desk with one glowing tool replacing a pile of old dev tools

Migration Gotchas and Fixes#

Some projects hit a Node.js compatibility gap during migration. Most have simple fixes.

The most common breaks and their fixes:

  • bcrypt (native C++ bindings) : replace with Bun.password, same algorithms natively
  • better-sqlite3 (same issue) : use bun:sqlite, Bun's built-in SQLite driver
  • canvas : no workaround at all. Stay on Node for that service.
  • argon2 : no workaround yet. Use bcryptjs as an alternative.
  • sharp : WASM fallback works, but test your specific transforms

Docker images are another pain point. The oven/bun base image is 450MB versus Node's 180MB slim image. Use a multi-stage build to keep production images lean:

Dockerfile
FROM oven/bun:1.3.11 AS build
WORKDIR /app
COPY package.json bun.lock ./
RUN bun install --frozen-lockfile
COPY . .
RUN bun build ./src/index.ts --target=bun --outdir=./dist

FROM oven/bun:1.3.11-slim
WORKDIR /app
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
CMD ["bun", "run", "dist/index.js"]

One Hacker News commenter flagged that "Docker hangs with Express servers and memory leaks with Prisma" are still reported. Worth testing your specific stack before committing.

Common Migration Questions

About 95-98% work unchanged. Bun reads your package.json and node_modules exactly like Node and implements N-API, so most native modules (compiled through node-gyp) load fine. The rare breakers are packages that reach into V8 internals directly rather than going through N-API. Pure-JavaScript and WASM packages are never a problem.

asked on community.latenode.com

Yes. Run bun install in any Node project without switching runtimes. It is the most common on-ramp. Bun writes a bun.lock alongside your existing package-lock.json, and the install speed alone (roughly 9x faster than npm, more on a warm cache) justifies adopting it for that one job while everything else stays on Node.

asked on community.latenode.com

Bun reads tsconfig.json and resolves paths aliases natively, with no ts-node, no tsconfig-paths package, no extra config for a standard single-package setup. Two known gaps to check before migrating: project references (references[] split across tsconfigs) and some monorepo alias layouts still have open bugs, so verify those actually resolve at runtime rather than assuming.

asked on github.com

Yes, via the official oven-sh/setup-bun GitHub Action and oven/bun Docker images. AWS Lambda runs through a custom runtime layer (~35% faster cold starts, 156ms vs 245ms). One real gotcha: older setup-bun versions did not cache ~/.bun/install/cache by default, so pin a recent version or add an explicit actions/cache step, or you will re-download dependencies on every run.

asked on github.com

When to Stay on Node.js#

New projects should default to the Bun JavaScript runtime in 2026. But migration is a different question.

Stay on Node if you need enterprise LTS guarantees. Node 22 LTS has a support timeline through April 2027, with a security-fixes-only window extending further.

Bun's release cadence is fast, but it doesn't offer long-term support branches yet. If your compliance team needs that paperwork, Node is the answer.

Heavy native C++ addons are the other deal-breaker. If your app leans on node:cluster for multi-process scaling, that API doesn't exist in Bun yet.

Bun uses a different concurrency model based on worker threads.

The honest take: if your team's existing toolchain works fine, and you're not feeling pain from slow installs or TypeScript compilation, there's no rush. Bun will be better in six months. Migrate when you have a reason, not because of benchmark screenshots on Twitter.

View paths as table
QuestionAnswerLeads to
Starting a new project?yesUse Bun
Starting a new project?noNeed LTS or C++ addons?
Need LTS or C++ addons?yesStay on Node
Need LTS or C++ addons?noFeeling install or build pain?
Feeling install or build pain?yesMigrate to Bun
Feeling install or build pain?noWait it out
Bun or Node for your project?
Tap a box to trace the path
yesnoyesnoyesnoStarting a new project?Use BunNeed LTS or C++ addons?Stay on NodeFeeling install or buildpain?Migrate to BunWait it out
View as table
SidePointWeight
ProNative TypeScript execution removes the build step entirelymajor
ProOne binary replaces node, npm, npx, and a test runnermajor
Propackage.json and most npm packages work unchangedminor
ConNo LTS branch yet, a blocker when compliance needs Node 22's support window into 2027major
Connode:cluster and some native C++ addons have no Bun equivalentmajor
ConFast release cadence means more upgrade churnminor
Should you switch to Bun?
Moving an existing Node service to Bun
For
  • Native TypeScript execution removes the build step entirely (major)
  • One binary replaces node, npm, npx, and a test runner (major)
  • package.json and most npm packages work unchanged (minor)
Against
  • No LTS branch yet, a blocker when compliance needs Node 22's support window into 2027 (major)
  • node:cluster and some native C++ addons have no Bun equivalent (major)
  • Fast release cadence means more upgrade churn (minor)

Default new projects to Bun. Migrate existing services only when install or build pain is real.

Assessment: author · reasoning in post

For teams evaluating their Windows development setup, Bun now ships native Windows binaries and works well with PowerShell and WSL2. One less reason to wait.

TL;DR: Use Bun for new projects. Use bun install as a drop-in package manager for existing ones. Migrate the runtime when you hit a specific pain point or start a new service. The acquisition by Anthropic means this project has funding, direction, and staying power for the first time.
Share