终于有人站出来,打算跟 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 是这种趋势的自然延续,但采取的却