终于有人站出来，打算和JavaScript生态正面竞争。这家伙知道他在做什么，他正在通过杀死JS 来描绘一个美丽的新世界。

2022 年，前Stripe 开发人员Jared Sumner 发布了Bun，这是一个用Zig 编程语言开发的运行时。据我所知，Bun最初只是一个JavaScript Web服务器，但在后续的发展中它逐渐发展出了彻底颠覆JS生态系统的野心。

以下是Bun 的主要好处，按照我个人注意到的顺序排列：

据说它提供了比Node 和Deno 更快的JavaScript/TypeScript 运行时包管理器。 Bundler—— 比NPM 和Yarn 快数亿倍，并且完全支持tsx、jsx、css、svg 等格式。用React-Script 替换Webpack，并以超快的速度提供您的所有内容。 提供非常快速的Web 服务器（Express 的替代方案）Sqlite 客户端Bread。

Bun的改朝换代的想法看起来很简单粗暴，但是我想用——JS有的，但是我的想法应该更简单，更高效。这里没有什么聪明才智，没有什么波折救国。你需要的是正面对决，一切都比JS好。使用低级语言编写极快的代码。这是包子。

Bun 还很年轻，可能还没有准备好应对现实世界操作用例的麻烦。但它的增长速度很快，所以我认为如果Bun能在几年内迅速获得市场份额，这是完全合理的。

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

我不知道你在实际工作中是否曾经编写过JS或TS生产代码，但是体验非常不愉快。虽然开源工具和小型项目在大多数情况下运行良好，但在商业和企业用例方面却常常表现不佳。由于传统的习惯路线行不通，公司别无选择，只能尝试不同的方法，以使他们的项目在生产中成功运行。

例如，TypeScript 解决了涉及多个开发人员的项目中的许多难题，因此只要JS 失败，您始终可以引入TS 进行代码转换。谨向微软表示诚挚的谢意。对于大型项目和整体存储库来说，NPM 太慢，因此企业可能需要迁移到Yarn。再次感谢脸书。简而言之，我们只是尽力将所有东西拼凑在一起，最终得到的结果在性能方面勉强还过得去。

作者表示，在公司的一个存储库上运行eslint 需要79 秒，因此唯一的选择是单独配置lint，使其仅在已更改的文件上运行。它引入了更多的复杂性，并且没有办法解决它。

一般来说，无数开发者使用自己的方法来加速JS 工具链的某些部分。例如，您可以使用Yarn 3 令人难以置信的“即插即用”节点模块虚拟化速度来替代NPM，或者使用基于JSON Schema 的请求解析器来解决Express 速度慢的问题。事实上，大多数原始工具都存在类似的问题，并且是由JS 开发人员为JS 开发人员编写的。如果用JS写的话会很慢.

结果，几种用更快的语言编写的更快的工具开始流行。每个拥有大型React 应用程序的公司可能都经历过WebPack 构建花费整整一分钟的痛苦。为此，我不得不改用Go 编写esbuild。同样，其他语言中eslint 的替代品也开始出现，例如Rome 用Rust 重写。

发髻是这一趋势的自然延续，但采用的是自下而上的方法。这个项目的核心思想是从头开始，用内置“电池”的低级语言重写整个JavaScript 生态系统。到目前为止，结果非常好。

Bun 现在可以做些什么？

让解释器快起来

如果Bun 重写了所有JS 助手，我会全力支持，但这将使其成为Node.js 的替代品。 Bun 并不懒惰，并努力让解释器本身更快。

Bun是用Zig编写的，运行在Apple开发的JavaScriptCore上，类似于使用v8的Node。 Zig 是一种新兴的低级语言，主要在C++ 主导的场景中蓬勃发展。我不是低级开发人员，所以我自己从来没有使用过它。我会将详细信息留给其他具有更多技术技能的博主。从本文中您只需了解Zig 可以帮助您更快地编写代码。对于JavaScriptCore，它的作用与v8 相同，只是v8 是由Google 提供的，而v8 是由Apple 提供的。 Safari 和许多其他Apple 项目都使用JavaScriptCore。

目前尚不清楚Bun 比Node 快多少，但据说在某些场景下要快得多。 io.js 刚诞生时，我的很多朋友可能还不在身边。总而言之，当时一个仅仅提高解释器速度的分叉就足以撼动整个JS 生态系统。 Bun 的启动速度比Node 快得多。在我个人的实验中，大约需要7ms，比Node.js 快10 倍左右，特别适合无服务器环境和边缘计算场景。

这波破坏不仅依靠速度优势，Bun还添加了很多很棒的标准库函数。例如，Bun.write() 是一个用于写入文件的新函数，它返回一个承诺，并声称可以通过使用更好的系统调用来进一步加快该过程。

就Node API 而言，Bun 目前支持大约90% 的现有Node API。节点非常大，并且总是包含您从未听说过的东西，更不用说使用过（例如new AsyncLocalStorage()），因此支持90% 就足够了。谁在NPM中运行所有包？根本没有必要，对日常开发基本没有影响。

顺便说一句，TypeScript 在Bun 很受欢迎。直接调用bun my-ts-file.ts。 Deno 的TS 支持仅达到这个水平。当您使用Bun 模板化新项目或将Bun 类型添加到tsconfig 时，IDE 的自动完成功能适用于这些新功能。

Bun 项目的最初目标之一是创建一个更快、更强大的TypeScript 编译器。尽管这个目标迷失在其他功能的海洋中，但它还是实现了。但是，目前我们还无法支持更高级的TypeScript 配置和功能，例如结合多种配置的装饰器和tsconfig 扩展函数。

替代 NPM

让我们来谈谈Bun 最令人兴奋的功能之一，——，它取代了NPM。真是快又快，足以让大家满意。

在Linux 上，bun install 的安装速度比npm install 快20 到100 倍。在macOS 上，它的范围可以是4 倍到80 倍。

它当然不如缓存快，但确实使它更快。这意味着它很快。

有许多解决方案致力于加速NPM。例如，熟悉的Yarn 即插即用想法是完全放弃node_modules 文件夹以加快包安装速度。它有一定的效果，但在实际使用中加速并不是那么大，并且涉及大量的填充和逃生舱口处理。它有效，但我个人不想再使用它，也不会推荐给任何人。

Pnpm 是另一个新兴的NPM 替代方案，它继续用TypeScript 编写，同时实现了一些智能优化。在pnpm 中，node_modules 是通过符号链接从全局缓存访问的，允许每个包在自己的时间安装，而无需等待其他包完成其当前操作。

Bun的基本思想与NPM相同，但速度更快。它有自己的锁定文件格式，node_modules 和package.json 看起来没有变化。如果您熟悉文件系统调用，则可以将低级访问与快速语言相结合，以实现非常快速的安装结果，而不需要任何特殊技巧。

目前，Bun 不提供工作区支持，因此您无法暂时连接到您希望存储的大型整体存储库（我们的项目也属于此类）。好消息是Bun 继续快速发展，几周前刚刚公布的路线图中提到了对工作空间的支持。

请注意，您不必完全切换到Bun 来将其用作包管理器、转译器或解释器。只需选择您想要的部分并丢弃其余部分。我想Bun早期的走红也可能会走这条路。因此，首先，它是一个有用的包管理器，稍后我们将讨论其余的内容。这降低了接受的门槛。

Bun

内含转译器，矛头指向 webpack、esbuild

包含一个用于Web 浏览器的转译器，显然是针对webpack 和esbuild。顺便说一句，Bun 的解析器是esbuild 解析器的Zig 端口，非常简单。

Bun 已经支持多种文件类型，包括css、svg、tsx、jsx、ts 等。 CSS for JS 等高级选项似乎也可以与Bun 配合使用。

Bun 包含带有多个内置模板集的项目脚手架，因此您可以直接在此处调用它们。

面包创建反应我的应用程序

然后我运行Bun dev 并在浏览器中运行React 应用程序。我认为你可以直接将react-scripts添加到Bun替换的工具列表中。

将文件扩展名从jsx 更改为tsx 将立即启用该程序。导入SVG，没问题。开发模式似乎也支持HMR，这是前端开发者使用Webpack的必备工具。

那么对于翻译人员来说，我们还缺少什么呢？毕竟生产环境的要求并不简单，所以我们还缺少很多东西。首先是最小化。这是真实用户在后续的开发路线图中最期待的功能。对于大型插件生态系统，还需要能够支持多种文件格式的打包工具。例如，目前.vue 文件和.scss 尚未实现。特别是.scss 已被几代开发人员使用，需要快速实施。 Bun 捆绑器的可插拔性如何还有待观察，但最重要的是它直接在框架内解决问题，而不需要依赖许多外部开源包。

其他功能——Web server 与 sqlite 客户端

Bun 还在标准库中添加了许多遗留框架元素。就我个人而言，我对这些库类型的功能并不真正感兴趣。毕竟，Node 已经具备了很多用于http 服务器的功能。

Bun的网络服务器看起来非常简单。 Express 有点落后于时代，但对于大多数开发人员来说仍然足够好（开发团队今年刚刚提供了承诺的支持）。 Bun 服务器似乎相当信任Cloudflare Worker。只要JavaScript 生态系统中的其他问题一一得到解决，Bun 的开发团队很可能会重新开始完善Web 服务器。请注意，在某些情况下，明智地使用系统调用可以使Bun Web 服务器的速度加倍，尤其是在文件处理期间。

至于新的SQLite 适配器，我认为之前在Node 中实现sqlite 的思路有点不符合一般人的想象。目前，大多数开发人员将旧版SQLITE 3 包与SQLITE 打包器结合使用，以提供对Promises 的支持。 Bun的解决方案看起来更简单，所以我很乐意使用它，即使它没有巨大的速度优势。

酒香也怕巷子深

我最担心的是，Bun 的许多优秀品质很难转化为对社区成员的实际吸引力。 Bun本身是JS生态系统的完全替代者。对于一般人来说，可能很难马上接受这么大的改变。

Bun 还很年轻，还没有完整的文档。对于大多数问题，我必须参考很长的自述文件。然而，创建一个docusaurus 站点并为具有完整内联注释的TypeScript 类型生成typedoc 并不困难，因此这个问题应该很快就会得到解决。

其他产品对比

服务端渲染React每秒HTTP请求数（Linux AMD64）对比，来自Bun官网

Deno

如果您从未听说过Deno 并且不打算了解它，请跳过本章。就我个人而言，我认为Bun 比Deno 更令人兴奋和更有前途。

Node 的创建者Deno 声称解决了一个长期困扰开发人员的问题。将es-modules 设置为默认并引入第一方TypeScript 支持（发布前无需转译NPM 模块）。但在我看来，Deno 在解决老问题的同时，也引入了很多新问题。

首先，Deno 对包解析和语法的改变是如此剧烈，以至于它们不再兼容原来的NPM 生态系统。换句话说，Deno 需要培育自己的新图书馆生态系统。 Deno 正在慢慢开始支持一些初始库，但我觉得项目的影响直接决定了开发的上限，所以我认为这就是Deno 的边界。当然有一些解决方法，例如CDN 将NPM 包转换为Deno 包，但我认为这不是一个好主意。

在我看来，Deno 还存在一些表明它正在开发中的问题，例如缺少package.json。 Deno 不允许开发人员为包编写可扩展元数据，无论是从模块解析角度还是由于缺少清单文件。 GoLang还专门为此目的引入了go.mod。

另外，我认为Deno 设计中的沙箱/权限系统应该是一个好主意，但不够细化。由于这是在包层次结构之外并且位于整个项目之上，因此大型应用程序最终将需要所有权限，并且问题又回到了原点。作为一家安全公司，我们对Deno 无法大规模保护应用程序免受供应链攻击感到失望。当然，Bun还没有说他打算如何解决这个问题。我只是在这里发泄一下我的不满。

综上所述，Van 的发展潜力比Deno 大得多。具体原因如下。

支持现有NPM 生态系统中的所有库以及您已编写的所有代码，而无需更改package.json。它解决了生态系统中的几个开放问题（特别是大型企业的需求），并将解决方案整合到一个框架中。这是人们已经习惯的工作方式，但速度更快。没有必要改变你的范式或强迫改变你的思维方式。只需使用它即可。如果你觉得Bun 拖慢了你的开发速度，但Webpack 太慢了，你可以放心，你可以直接使用那个包管理器。它几乎在每个方面都更快，这是一个巨大的优势。正如您在io.js 中看到的那样，人们愿意为了性能而改变阵营。

Rome

正如前面提到的，Rome 是一个验证者。 Rome 的维护者已经开始用Rust 而不是JS 重写它，79 秒的验证时间有点夸张。 （这是一个谎言。Eslint 用了79 秒。）

从路线图来看，Rome还计划引入捆绑器、文档生成器、压缩器、类型检查器、测试框架等。但这还没有结束，Bun 显然还要走得更远。至少Rome 还没有开始重写Node 核心本身，所以我认为这就是影响的程度。

简而言之，许多项目都发现了Node 生态系统中存在的问题，并且每个项目都试图通过集成的高性能框架来解决这些问题。那么就看谁发展得更快了。

开源世界中的生态阵营

下面我想把自己的视角缩小一点，通过具体的例子来谈谈开源世界的生态营是如何实现的。

我相信许多Node 开发人员都知道Jest 如何克服Mocha 测试框架并迅速崛起。 Mocha 也是当时人们首选的测试运行器，具有良好的结果和良好的语法，但就更复杂的需求和断言而言，我们不得不引入其他模块和插件。幸运的是，由于社区协作，寻找插件并不那么困难。这意味着开发人员需要更广泛的知识来实现相应的库。

Facebook 随后提出了Jest，一个包含“电池”的测试框架。它借用了Mocha 的语法和库，并将所有内容集成到一个框架中。 Jest 可以解决从锻造时间到需求发现和模拟的所有问题。 Jest 有扩展的空间，但我在现实生活中只使用过一次。大部分概念和设计的验证都是由Mocha 完成的，而Jest 只是后来者，巩固了这一努力并使其更容易理解。 Mocha 拥有忠实的追随者，但Jest 是迄今为止最受欢迎的。

开源世界里这样的例子还有很多。开创性的解决方案获得先发优势，当增长停滞时，热情的开发人员就会集成功能。这让我想起了Linux家族还没有集成的时候的systemd。 systemd 现在几乎可以在大多数Linux 发行版上运行所有内容，Bun 可能也会席卷JavaScript 世界。

我知道，从开源的角度来看，这种合并和集成似乎违背了开源精神，但使用大量的库来完成简单的需求对于开发人员来说无疑是一个好主意。对于一些人来说是痛点。而如果每个图书馆都有相应的维护团队，恶意黑客就可以简单地欺骗电子邮件域来进行供应链攻击。我们不希望这样的事情发生，但现实却很残酷。老兵也容易受到此影响，还有第一次不知道很多名字或还不熟悉各种语言的新人。所以，从实际的角度来看，很多朋友和我一样，更愿意将更多常用的功能引入到标准库中，或者将多种开发工具集成到一个统一的框架中，我认为他们不这么认为。历史性的逆转。

结束语

截至2022 年7 月，Bun 尚未准备好投入生产，但我们强烈鼓励大家安装并尝试。整个过程非常方便，我感觉目前的Bun足以处理小型子项目和简单的内部仪表板。

我不确定Bun 是否会、甚至如何在未来几年内重建JavaScript，但我真的很期待它的发展。

原文链接：

https://www.lunasec.io/docs/blog/bun-first-look/

版权声明：本文转载于网络，版权归作者所有。如有侵权，请联系本站编辑删除。