前端技术演化史

Bun

Properties1
tags运行时, bun, zig, 性能, 一体化, javascriptcore

7分钟阅读

🥟 Bun

一句话定性

2022 年,Jarred Sumner 用一门冷门系统语言 Zig 写出了 Bun。它不谈理想主义,只谈一件事:快。运行时、包管理器、打包器、测试器四合一,且兼容 Node 生态——它要做的不是”更好的设计”,而是”更快的、什么都不用换的 Node”。

一、它是什么 & 出现的时代

Bun 是一个用 Zig 编写、基于 JavaScriptCore 引擎(苹果 Safari 的引擎,不是 V8)的 JavaScript 运行时,2022 年由 Jarred Sumner 发布(2023 年 1.0)。

它的定位非常激进——All-in-one(一体化工具箱):

你原来需要Bun 一个就够
Node(运行时)bun run
pnpm(装包)bun install(快几十倍)
Webpack/esbuild/Vite(打包)bun build
Jest/Vitest(测试)bun test
ts-node/tsx(跑 TS)原生执行
dotenv(读 .env)内置

为什么用 Zig + JavaScriptCore?

  • Zig:无运行时、无 GC、可精细控制内存,能写出比 C 还激进的优化代码,且编译期能力强。
  • JavaScriptCore(JSC):启动速度比 V8 更快(苹果为 Safari 极度优化过冷启动),Bun 押注”启动快”对 CLI 工具和 Serverless 至关重要。

二、为什么会出现(解决上一代什么痛点)

Bun 瞄准的痛点

  1. 工具链碎片化:跑个项目要拼 Node + 包管理器 + 打包器 + 测试器 + TS 转译器,五个工具五套配置。
  2. 太慢:npm install 慢、Jest 慢、冷启动慢——开发体验被”等待”切割得支离破碎。
  3. Deno 的教训:Deno 设计很美但不兼容 Node 生态,推广受阻。Bun 吸取教训——直接兼容 Node,零迁移成本。

Bun 的第一性判断:开发者不想换生态,只想要更快、更省心。 与其像 Deno 那样”做正确的新世界”,不如”把旧世界做得飞快”。

三、核心机制 & 为什么流行

1. 极致速度(灵魂卖点)

bun install   ──► 比 npm 快 10~30 倍(并行 + 优化的缓存/链接策略)
bun run       ──► 启动比 node 快数倍(JSC 冷启动 + Zig 实现)
bun test      ──► 比 Jest 快数倍(原生实现,无 transform 开销)

从 IO 调度到内存分配,大量热路径用 Zig 手写优化,绕开了 JS 工具的性能天花板。

2. 兼容 Node(关键差异化)

Bun 实现了 Node 的核心 API(node:fs、node:path、process、Buffer……)和 npm 协议。你的 Node 项目大概率直接 bun run 就能跑——这是它比 Deno 更易被采纳的根本原因。

3. 原生支持一切现代格式

.ts / .tsx / .jsx / ESM / CJS 开箱即用,无需配置转译器。同时也内置 Web 标准 API(fetch、WebSocket 等)。

4. 内置极快的工具

bun build(打包)、bun test(测试)、Bun.serve(高性能 HTTP)、内置 SQLite 驱动……减少依赖、减少配置。

一句话理解三者差异

  • Node.js:生态之王,稳但旧。
  • Deno:理想主义者,正确但曾自绝于生态。
  • Bun:实用主义者,“我不重新发明世界,我只是让你的世界快十倍”。

四、带来的新问题 / 副作用

速度之外的代价

  1. 成熟度与稳定性:作为最年轻的运行时,边缘 API、罕见库的兼容性偶有坑,生产环境采用需谨慎评估。
  2. Node 兼容永远是”追赶”:只要 Bun 不是 Node 本身,就总有 1% 的 API 行为不一致,而那 1% 可能正好卡住你。
  3. JSC vs V8 的生态差异:大部分人基于 V8 心智模型(性能特征、调试工具),换引擎带来微妙差异。
  4. 加剧运行时碎片化:又多了一个要兼容的目标,库作者负担更重(二阶效应)。

五、现状 / 演化

  • 增长极快,以”最快的包管理器”为切入口被大量项目采用(很多人即使不用 Bun 运行时,也用 bun install 装包)。
  • 1.0 后持续完善 Node 兼容性,逐步进入生产环境。
  • 倒逼整个生态提速:Node.js 加内置 test runner,各工具竞相优化冷启动——Bun 把”快”重新设为行业基准线。

六、对后续技术的影响(因果链)

   工具链碎片化 + 太慢          Deno 的教训(不兼容 = 推不动)
            │                          │
            └──────────┬───────────────┘
                       ▼
                 Bun(2022, Zig + JavaScriptCore)
                       │
   ┌───────────────────┼─────────────────────┬──────────────────┐
   ▼                   ▼                     ▼                  ▼
 极致速度          一体化(运行时+包+        兼容 Node 生态      原生 TS/JSX
 (Zig 手写)        打包+测试)              (零迁移成本)        (无需配置)
   │                   │                     │                  │
   ▼                   ▼                     ▼                  ▼
 重设"快"的基准线   对抗工具链碎片化      规避 Deno 式失败    简化开发体验
   │
   ▼
 倒逼 [[Node.js]] 提速、内置 test;倒逼 [[Deno]] 拥抱 npm 兼容

历史地位

Bun 是运行时之争里的”实用主义胜利方法论”:它没有 Deno 那样的哲学包袱,只用”快”和”兼容”两张牌,就在 Node.js 主导的市场里撕开了口子。它和 Deno 一道,把整个 JS 运行时生态推向了更快、更标准、更一体化——这正是 JS运行时演进史 这条”性能 → 生态 → 反思 → 重做”螺旋的最新一环。

🔗 相关:JS运行时演进史 | Node.js | Deno | npm-Yarn-pnpm-包管理 | Webpack | Vite | TypeScript | ES-Modules

关系图谱

反向链接