查看原文
其他

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

Jim Bytebase 2022-12-19

最近前端圈子又有了新的话题,重量级轮子 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


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存