Skip to content

SYSTEM Cited by 1 source

Bun

Bun (bun.com) is a JavaScript and TypeScript runtime, bundler, test runner, and package manager, built in Zig. Positioned as a Node.js-API-compatible alternative, it uses Apple's JavaScriptCore engine (not V8) and includes its own I/O and scheduling layer optimised for CPU-intensive and streaming workloads.

Why it shows up on this wiki

Canonical instance of a runtime disclosed to outperform Node.js on specific CPU-bound and streaming- SSR workloads while being slower on cold starts. Named differentiator vs Node: "optimized I/O and scheduling that reduce overhead in JavaScript execution and data handling".

First wiki appearance via the 2026-04-21 Vercel Functions integration launch (Source: sources/2026-04-21-vercel-bun-runtime-on-vercel-functions).

Performance characteristics (per 2026-04-21 Vercel disclosure)

Canonical comparison table from Vercel's benchmark:

Category Bun Node.js
Performance Faster for CPU-intensive and streaming workloads Reliable and consistent across workload types
Cold starts Slower than Node.js due to runtime initialization overhead Mature and well-optimized
Compatibility Implements Node.js APIs with growing coverage; edge-case differences may exist Full ecosystem compatibility
Ecosystem maturity Rapidly evolving; smaller community Stable and widely supported
Best use Performance-critical applications Default for broad compatibility and production stability

Load-bearing numeric disclosure: 28 % average latency reduction in CPU-bound Next.js rendering workloads (TTLB, 1 vCPU / 2 GB, iad1). React SSR / SvelteKit / vanilla JS: "similar across platforms" — no cross-runtime gap. The gap is concentrated in Next.js's streaming SSR path specifically, attributed to Bun's handling of Web Streams + reduced GC overhead versus Node's current Web-Streams implementation.

Integration with Vercel Functions

Opt-in at project scope via vercel.json:

{
  "bunVersion": "…"
}

Runs on Fluid compute with Active CPU pricing. No emulation layer — "code runs exactly as it does locally" (patterns/multi-runtime-function-platform). TypeScript supported with zero configuration. Launch-support framework set: Next.js, Express, Hono, Nitro.

Known limitations

  • Slower cold starts than Node.js — runtime-initialisation overhead not yet optimised. Material for low-traffic + latency-sensitive endpoints where cold-start p99 dominates.
  • Partial Node.js API compatibility — "edge-case differences may exist". Vercel explicitly recommends "Test your dependencies under Bun before migrating production traffic to confirm expected behavior."
  • Smaller ecosystem + community than Node's OpenJS- Foundation-hosted project with decade-plus of library support.
  • Public Beta on Vercel at time of writing (2026-04-21); no SLA.

Cross-runtime context

  • vs Node.js: Same language surface (JS
  • TS), different engine (JavaScriptCore vs V8), different runtime I/O scheduler, different Web-Streams implementation. Node is the compatibility + cold-start choice; Bun is the performance choice per 2026-04-21 Vercel disclosure. Important counter-lever: the 2026-04-21 fast-webstreams disclosure (sources/2026-04-21-vercel-we-ralph-wiggumed-webstreams-to-make-them-10x-faster) shows Node's Web Streams gap is closable at the library/upstream level — systems/fast-webstreams on Node reaches 14.6× native Node Web Streams on the React Flight pattern. This partially contests the runtime-switching argument: the Node-side gap is an implementation issue, not a V8-vs-JavaScriptCore fundamental. The Bun streaming-SSR advantage is specifically against current Node Web Streams; how much margin remains once PR #61807 lands and fast-webstreams rolls out is an open question the wiki will re-measure when data arrives.
  • vs Cloudflare Workers: Different isolation model — Bun is process-level like Node; Workers run user code inside V8 isolates. Different streaming implementations; Cloudflare's profiling of the same benchmark (sources/2025-10-14-cloudflare-unpacking-cloudflare-workers-cpu-performance-benchmarks) surfaced the same Node-side Web-Streams cost.

Seen in

Last updated · 476 distilled / 1,218 read