Bun 1.4 shipped on August 20 with its entire runtime rewritten from Zig to Rust — a six-day, AI-assisted migration of nearly a million lines of code that has the developer community split between “impressive engineering” and “vibecoded disaster.” Both reactions are understandable. Neither is the most important thing here. The real story is six new built-in APIs that collectively replace sharp, Playwright, marked, node-cron, and node-pty. In one release, gone.
Six APIs That Trim Your package.json #
Bun’s long game has always been to eliminate the npm dependency stack entirely. Version 1.4 takes the biggest step yet toward that goal.
Bun.Image replaces sharp with a chained API that runs 1.38× faster on decode-resize-encode workflows. It handles JPEG, PNG, WebP, HEIC, AVIF, GIF, and BMP without any native build step.
Bun.WebView replaces Playwright and Puppeteer. It uses system WebKit on macOS or Chrome/Edge over CDP everywhere else. No browser binary to install, no flaky async-session management — just a handle you can navigate and click.
Bun.markdown replaces marked and remark. It is 138× faster than marked.parse()
, supports GitHub Flavored Markdown tables and task lists, and can render to ANSI escape codes for terminal output directly.
Bun.cron() registers OS-level cron jobs (crontab on Linux, launchd on macOS, Task Scheduler on Windows) and prevents overlapping runs without extra infrastructure. Bun.Terminal provides a full PTY interface without node-pty. Native parsers for JSON5, JSONL, JSONC, XML, and TOML round out the list.
// Before: four packages in package.json
import sharp from "sharp";
import { chromium } from "playwright";
import { marked } from "marked";
import cron from "node-cron";
// After: zero packages
const thumb = await Bun.file("photo.jpg")
.image()
.resize(800, 600)
.webp({ quality: 85 })
.write("thumb.webp");
await using browser = new Bun.WebView({ width: 1280, height: 720 });
const html = Bun.markdown.html("# Hello world");
await Bun.cron("./task.ts", "0 9 * * *", "daily-run");
The approach is deliberate. Every built-in API is an argument that third-party packages introduce fragility, version drift, and cold-start overhead. With 1.4, Bun makes that argument more convincing than ever.
The Performance Numbers #
The Rust rewrite was not purely ideological — there was a concrete problem to solve. Memory leaks in the Zig runtime were spiking Claude Code sessions to 14–23 GB, which is what happens when your biggest customer is also your owner and they have the compute to notice the problem.
The results against Bun 1.3 are measurable:
- Idle CPU usage: down 80%
- Express server memory: 169 MB → 92 MB (−46%)
- Linux startup: 10.9 ms → 5.1 ms (2× faster)
- First install: 15× faster than npm, 30× on fresh checkout
- URL parsing: 4.6× faster. Markdown parsing: 138× faster.
A word of context on Bun versus Node.js: synthetic HTTP benchmarks show Bun at 52,000 req/s versus Node’s 13,000 — a 4× lead. Real-world applications with a Postgres layer show Bun at 12,400 versus Node’s 12,000. When your bottleneck is the database, the runtime barely registers. The startup advantage (Bun at ~290 ms versus Node’s ~940 ms) remains real and matters most for serverless and edge deployments.
About That Rust Rewrite #
The controversy is real and worth understanding. Claude AI agents converted 570,000 lines of Zig to 682,000 lines of Rust in six days. The resulting PR — the largest in GitHub history — was reviewed by AI bots, not humans. The code contains 13,044 unsafe
blocks and 999 uses of static mut
, compared to roughly 73 unsafe blocks in a typical hand-written Rust project of similar size.
That number sounds alarming. The more useful framing: these unsafe blocks make risks visible that were hidden in Zig. Rust’s borrow checker now enforces constraints that previously relied on developer discipline. The immediate goal was stopping the memory leaks; the longer-term goal is cleaning up those unsafe blocks iteratively. Whether the Bun team follows through is the open question.
One data point in favor of stability: Claude Code has been running the Rust version of Bun in production for over a month before the public release. Prisma Compute also launched on it. Vercel now supports Bun 1.4 in Vercel Functions, available by setting bunVersion: "1.4.x"
in your vercel.json
.
Should You Upgrade? #
Bun 1.4 upgrades are explicit opt-in and include breaking changes — check the breaking changes tracker on GitHub before touching production. For most code, existing Bun.sql and Redis client implementations work unchanged.
Non-critical and greenfield projects: Upgrade now. The performance gains and new APIs are worthwhile.Production, latency-sensitive systems: Wait one or two point releases. WebSocket handling and native module compatibility are the known rough edges.Serverless and edge: High upside from the startup improvement. Test your specific framework and upgrade.
Node.js compatibility now targets Node 26.3.0 (up from 24.3.0), with 1,517 additional tests passing. Playwright, Next.js 16, AWS SDK S3, gRPC, and OpenTelemetry all work on Bun 1.4 — the ecosystem gap that held many teams back is meaningfully smaller.
The bigger picture: the JavaScript runtime space is being rebuilt in Rust underneath developers who may not notice for another year. pnpm did it, Rspack did it, Biome did it. Bun just did it at the most ambitious scale yet. Whether the AI-assisted rewrite approach becomes a new normal or a cautionary tale depends almost entirely on what the next six months of point releases look like.