试图颠覆 JavaScript 生态？亲身试用新 JS 运行时 Bun 后，我觉得未来可期

终于有人站出来，打算跟 JavaScript 生态系统正面交锋了。这家伙知道自己在干什么，而且也描绘出了干掉 JS 之后要创造的美好新世界。

2022 年，前 Stripe 开发人员 Jared Sumner 发布了 Bun ，一种用 Zig 编程语言开发的运行时。据我所知， Bun 最初只是种 JavaScript webserver，但在后续发展中逐渐酝酿出了全面颠覆 JS 生态系统的野心。

按我个人的关注度排序，Bun 的优势主要有以下几点：

• 据说能提供比 Node 或 Deno 更快的 JavaScript/TypeScript 运行时

• 包管理器比 NPM 或 Yarn 都快上亿倍

• Browser Bundler——全面支持 tsx、jsx、css、svg 等格式，能替代从 webpack 到 react-scripts 的所有内容，而且速度仍然快如闪电

• 提供速度极快的 webserver（替代 Express）

• Sqlite 客户端

• Bread

Bun 改朝换代的思路看着非常简单粗暴——JS 有的我也要有，而且我的要更简单、更高效。这里没有小聪明、没有曲线救国，要的就是正面对抗而且样样比 JS 强。用一种低级语言，编写出运行极快的代码，这就是 Bun。

Bun 还很年轻，也许还没准备好迎接那些令人头大的真实生产用例。但它确实发展迅速，所以如果 Bun 真能在几年后快速占据市场份额，我也觉得完全在情理之中。

之前的方案到底有什么问题？

不知道大家在实际工作中有没有编写过 JS 或 TS 生产代码，那种体验挺难受的。多数情况下，开源工具和小项目也能良好运转，但一到商业和企业级用例上就经常掉链子。而因为传统、常规的路线走不通，企业只能试遍各种办法让项目能在生产环境中正常起效。

例如，TypeScript 在涉及多位开发者的项目中解决了不少老大难问题，所以只要 JS 的路子走不通，我们就能随时引入 TS 进行代码转换。这里要真心感谢微软。NPM 对大型项目和单体 repo 来说速度太慢，所以公司可能需要转向 Yarn。这里又要谢谢 Facebook。总之，我们就是在拼了命地东拼西凑，最终搞出性能勉强说得过去的成果。

作者提到自己所在企业的整个单体 repo 执行 eslint 需要耗费 79 秒，所以只能单独配置，保证只对发生变更的文件执行 lint。虽然会引入更多复杂元素，但也没有办法。

总的来说，无数开发者都在用自己的办法加速 JS 工具链中的某些特定部分。比如用 Yarn 3 那疯狂的“即插即用”节点模块虚拟化速度来替代 NPM，或者用基于 JSON Schema 的请求解析器解决 Express 的低速问题。其实大多数原有工具都有类似的问题，而且它们是由 JS 开发者编写、专为 JS 开发者服务的。用 JS 编写，就等同于速度很慢……

于是，一些用更快语言编写的高速工具开始流行起来。每家拥有大型 React 应用程序的企业，肯定都经历过 WebPack 构建要花掉整整一分钟的折磨。为此，他们必须转向用 Go 语言编写 esbuild。同样的，其他语言版本的 eslint 替代方案也开始出现，比如用 Rust 重写 Rome。

Bun 是这种趋势的自然延续，但采取的却是自下而上的推进路