新宠儿还是新玩具？Bun 速览

最近前端圈子又有了新的话题，重量级轮子 Bun。它自称是集 Bundle, transpile, install and run JavaScript & TypeScript 于一身的全能 runtime，对标 node 和 deno 并且有比它们快的多得多的速度。在首页的显著位置直接给出了 http serve 和 sqlite 三倍于 node 的性能对比图，可谓贴脸输出。

一般这种听起来就跨时代的产物第一反应都难免让人觉得是诈骗，所以就花一点点时间，对它进行一个浅层速览吧！

为什么快？

官网没有详细的资料，只作了一些简单的解释：

• Bun 用苹果的 JavaScriptCore 而非 V8 作为 JS 引擎，因为 JSC 启动和执行比 V8 更快。但链接给出的测试实在是太过于粗糙，如果认真对比的话还是要看看更全面的 benchmark。
• Bun 是用 ZIG 语言编写。ZIG 是一门比较小众的系统级语言，常被用来对标 C/C++ 和 rust，这不巧了么，后两者刚好是 node 和 deno 所采用的语言。ZIG 能手动管理内存，这是它成为高性能语言的基础之一。另一个亮点是『编译期函数 compile-time function』，有点元编程的意思，比如 ORM 的表值映射可以通过编译期函数直接生成目标代码。
• Bun 徒手撸了很多东西，包括 JSX/TypeScript 的转译器、打包工具、SQLite client、HTTP client 等等。并且进行了『很多优化』。这……难道不是因为 ZIG 的标准库啥都没有，只能从头撸吗？这也不难解释它在 HTTP serve 和 SQLite 项目的测试上取得很好的成绩，应该做了很多针对性优化吧。

单从以上几点看的话，感觉即使现在性能很强，可能也只是作为一个新项目初期的后发优势，毕竟像 node 这样的成熟项目在迭代过程中性能的优化和劣化是在同时发生的，不用太纠结 ***x faster 的问题。

标准库

Bun 的标准库么，嗯只能说很烂。当然一定程度上是因为 ZIG 的标准库就很烂，造成 Bun 很多东西都只能从头手撸。那么目前有什么呢？官方说的是这样：

其中 fs 和 path 我试了一下，用起来和 node 没什么区别，其他没有尝试。

我有点好奇它的「use the fastest system calls available with Bun.write to write, copy, pipe, send and clone files」指的是什么。我们知道 node 用的是 libuv，它在 linux 上的实现是 epoll，那么 Bun 的 IO 用的是什么技术呢？会是听起来很先进但（似乎）没有广泛应用的 aio 吗？我暂时没有深入去查找资料。

对于 node_modules 这块我比较存疑，因为我的几个简单 node CLI 项目，依赖也不复杂，但是用 Bun 并没有跑起来。后来经过一番二分 debug 发现是它似乎无法正确处理用中文字符做 object literal 的 key，需要像正规 JSON 一样给 key 加上引号，然后勉强运行起来了。虽然不是什么大问题，但过程中几乎无法得到任何有用的报错信息，偶尔有些报错也歪得挺离谱。

Bun 自称它有非常快的 ffi，但它的标准库却是用 ZIG 手撸的，并没有发现移植了现成的各种 C lib 进来，所以这块也不知道作者是如何考虑的，为何不发挥 ffi 的优势移植一堆优秀的 lib 进来快速扩充 Bun 的标准库呢？

Transpiler 也是生撸的，这块一方面是 bug 肯定少不了，另一方面是以后怎么追赶 JSX 和 TS 的迭代会是个问题。

最后是在它介绍当中的 bundler 部分，目前似乎还只是作者规划的美好愿景。

生态

光有 runtime 本身固然没什么用，还需要有各种生态，那么目前 Bun 的生态如何呢？我只能说：略大于零。

官网里这么写：

对于 bun run，上面也说到了，用现成的 node_modules，我试了几个项目都并没有跑起来。要将 node 项目迁移到 bun 目前看来不是很现实。

对于 bun install，我也尝试了，不论是开还是不开代理，都没有安装成功，加上 verbose 参数也没有看出来什么端倪，中间不知道为什么就卡住了。我们知道 npm, yarn, pnpm 在 install 速度上的差异一方面来源于下载包，一方面来源于解析依赖，由于我没有成功执行 bun install 于是也无从继续分析。

开发健康度 & 社区

到今天（2022/07/15）为止，Bun 的 github 提交频率都非常高，每天都有 commit，目前有 200+ open issue 和 20+ pending pr，而且 issue 很多都是最近几天甚至几小时提的，可以看出是有不少人在尝鲜的，活跃度还不错。

从 open issue 大概看看，主要的 bug 有这几种

• seg fault、illegal instruction 这类 runtime 问题，并不太确定是 Bun 还是 ZIG 的问题

• 使用 Bun 标准库，如 fetch、HTTP、SQLite 等出现的问题
  

• 引用 nodejs 库遇到的问题

这么看的话问题还是在各个维度上都有的，作为一个早期项目来说这可以理解，另外就是估计这些 bug 全修了的话性能优势会抵消不少 😂

另外就是作者 Jarred-Sumner 战斗力极强，从去年 4 月份到现在，有超过 90% 的代码都是他一个人写的，达到了 2,764 commits   1,678,425 ++   998,768 --，从这澡堂瓷砖一样的 calendar 也可见一斑。

小结

即使是 deno，从 1.0 到现在已经 2 年了，该没人用还是没人用，更别说 deno 从初版到 1.0 也熬了有接近 2 年的时间。deno 这么努力也流行不起来，大概是 JS 生态真的不太需要一个新的 runtime 吧。代价那么大，收益却全靠吹，实在是让人提不起劲来。

nodejs 一开始虽然也因为异步 IO 而吹它的性能比 PHP、Java Servlet 快多少云云，但最后选择 node 的项目却大概率不是因为性能而选的。现在 node 成为了前端工具链的枢纽，同时也在服务端有了一定的生态位，更多是因为它占了一个从无到有的先机，后来者想要取而代之恐怕是非常的难了。即使最近一两年来，前端生态圈刮起了一阵用 rust 重写的风，比如 swc，rome，大多也是集中在关键性能的部分，最终还得结合 node 生态才能融入到工具链。
一家全球化初创公司背后的 30+ SaaS 服务和成本资深工程师教你写出研发喜欢的文档
将 MySQL 数据库恢复到某个时间点
Bytebase 1.2.1 - 2022.7.7