Bun 会是 Webpack 之后的下一件大事吗？

源码 · 2024-10-3 15:59:00

JavaScript 工具的未来将离 JavaScript 越来越远，一些工具（如 Webpack 和 Babel）的紧张性正在日益降落。为什么？
现在已经证明一些语言（如 Rust、Go 乃至 Zig）在捆绑、转译和编译方面比 JavaScript 具有更好的性能。它们不是单线程的，这在处置惩罚大量文件方面具有上风。
是什么缘故原由导致肯定要用 JavaScript 开发生态体系的工具？毕竟这些工具紧张运行在开发职员的机器上，而不是在欣赏器上。别的，JavaScript 开发职员不必要调试这些工具的内部代码。
SWC 是最早摆脱 JavaScript 的工具项目之一，不久之后，Esbuild 发布了，很多人为之高兴不已，由于在性能方面表现精彩，它们成了真正的游戏规则改变者。现在，Vite 2.0 正在底层利用 Esbuild 来提供高性能的构建体验。
迩来，JavaScript 工具生态体系中出现了一个新成员——Bun。它的目的是让整个 JavaScript 开发过程更加快速，这是一个万能的工具，它不光加快了编译和剖析的速度，还提供了自己的依赖项管理器工具和捆绑。
这个工具还没有为在生产环境中利用做好准备，但它的未来看起来很光明。本文将先容这个新工具，以及它与 NPM、Esbuild、Babel 和 Webpack 之间的对比。
概览

与其他利用 Rust 或 Go 开发的工具差别，Bun 是用 Zig 开发的。Zig 是一种通用的编程语言和工具链，用于开发和维护坚固、优化和可重用的软件。
只管它是重新开始开发的，但开发者接纳了与 Esbuild 项目类似的开发方式。
Bun 支持一些开箱即用的复杂特性，如 TypeScript、CSS in Js、JSX，不外还缺少一些根本功能，如源映射、Minifier、摇树优化等。
Bun 的一个显着特性是它提供了自己的 Node 模块剖析器实现，这是最值得关注的优化之一。
与 NPM 和 Yarn 一样，Bun 也会创建锁文件，叫作 bun.lockb。这里必要注意的是，它天生的是二进制文件，而不是纯文本文件。为什么是二进制文件？紧张是出于性能的思量。弊端是未便于我们检查 PR 的厘革。
检查锁文件的唯一方法是利用下面的下令：
bun install -yBun 现在支持下面这些加载器：

安装设置

Bun 还不是一个公开项目，你必要加入他们的 Discord 频道并发出约请哀求。在进入 Discord 后找到他们的 #invites 频道，然后在“I want bun”频道上发起约请哀求。
你将得到一个一次性的 jarred-sumner/bun 代码库约请。
要安装 Bun，你必要执行下面的下令：
curl -fsSL https://bun.sh/install | bash检查是否可以正常运行：
bun --version你会看到它还没有到达 1.0.0 版本。正如我前面提到的，它还没有为在生产环境中利用做好准备。
利用
它的用法很简朴。如果你熟悉 Yarn 或 NPM，你会发现它们险些是一样的。
安装包：
bun install与 Yarn 一样，它将利用已有的 package.json 与锁文件（如果有的话）的组合。
添加或删除包：
bun remove react我们可以将 Bun 作为执行器：
# instead of `npm run clean`它通过 create 下令提供了与最新的 React 生态体系的一些集成。
我们来创建一个 Next.js 应用：
bun create next ./app我们来创建一个 Create-React 应用：
bun create react ./app怎样天生捆绑文件？
运行bun bun ./path-to.js可以天生 node_modules.bun 文件，它包罗了全部导入的依赖项。
你可以通过执行./node_modules.bun > build.js来查察包的内容。
基准测试

让我们通过运行一些基准测试来相识它的速度。固然，这些都是近似的丈量值，而且跟运行环境的设置有关。由于这是开发职员的工具，以是我紧张关注最常见的开发任务：

启动开发服务器；
对文件做一些修改；
安装包；
构建生产发行包；
创建一个新的 Web 应用步调。

作为参考，我的条记本电脑配备了 AMD Raizen 7 CPU 和 16GB 内存，体系是 Ubuntu 20.04。
我利用了一个天生随机 jsx 文件的工具。我天生了 21 个随机的 jsx 文件，我将它们包罗在全部测试项目中。
Bun 与 Babel

这个对比大概不是很公平，但它确实让我们看到这个工具与传统工具相比是多么的快。

创建一个 Create-React 应用

我们可以看到，利用 Bun 和 Webpack+NPM 创建 Create React 应用之间的显着区别。前者险些没有任何延长，只必要 4.4 秒就可以完成全部设置。

创建一个 Next.js 应用

之前的效果实在并没有那么令人印象深刻，毕竟我们已经风俗了用其他工具痛击 Webpack。我们来举行一场公平的战斗，比较一下 Bun 和 SWC。

两者之间的差别非常显着，特殊是在处置惩罚文件变动方面。在我的条记本电脑上，Bun 只必要 10 毫秒，而 SWC 必要 70 毫秒。
包管理器

在模块的安装和操纵方面，Bun 也有一些上风。其他工具依赖 NPM 或 Yarn 来完成这项工作，Bun 的性能大约比 NPM 快 4 到 100 倍。
我们已经第二步中看到了两者的巨大差别。不外，我们如今来做一个更根本的例子。我们创建一个 package.json 文件，此中的依赖项如下：

date-fns@2.28.0——89.5KB
jspdf@2.5.1——339.1KB
react@17.0.2——6.9KB

然后我们对第一次安装和基于缓存安装举行基准测试。为了让差别更加显着，我选择了一个大型的库（jspdf）。

时间差别很显着。如果通过网络安装，速度快 4 倍，如果从缓存中剖析，速度会快更多。
Bun 与 Vite
Esbuild 是 Bun 真正的竞争对手。对于这个测试，我利用了 Vite，由于它内部利用了 Esbuild。
Bun 与 Vite 在开发服务器方面的对比

我还基于之前雷同的代码利用三个紧张工具天生了捆绑包。必要注意的是，我们不发起在生产环境中利用 Bun，由于它缺少了相当多的特性。只管基准测试效果令人印象深刻，但我们还是要持审慎的态度。
在最坏的环境下，最长构建时间是 7 秒。这三个工具在这方面做得很精彩，不是没有原理的。

Bun、Vite、SWC 构建一个用于生产环境的捆绑包
总结

JavaScript 工具从未像如今这么好过，纵然这个工具还没有为在生产环境中利用做好准备，但出现了新的竞争对手总是一件功德。Webpack 的未来还不清朗，它在 JavaScript 范畴内外都有很多竞争对手。
Bun 并不是万能的工具，它善于的是构建网站和 Web 应用。如果要构建库，Bun 团队发起利用 Esbuild，乃至 Rollup。
如今，Bun 开发团队的重心仍旧不在生产停当方面，他们专注于开发以及与现有框架和工具的兼容性。

原文链接：
https://betterprogramming.pub/is-bun-the-next-big-thing-after-webpack-d683441f77b9

Bun 会是 Webpack 之后的下一件大事吗？

所属分类: 问答交流

新帖推荐: 30日

推荐作品