Bun 是什么? 为什么要用 Bun? 它解决了哪些 Node.js 的问题?

在 JavaScript 社群讨论度极高的 Bun 1.0 正式发布了。然而，你知道 Bun 是什么? 为什么要用 Bun? 它解决了哪些 Node.js 的问题? 让我们透过本文一起来了解。

什么是 Bun?

Bun 是 JavaScript 的执行环境，也就是能跑 JavaScript 程式的地方。目前社群最多人用的 JavaScript 执行环境莫过于 Node.js。因为 Node.js 在设计上有些问题，但打掉重练的成本太大，所以他的创作者 Ryan Dahl 后来另外开发了 Deno 这个新的执行环境，来解决那些问题。而 Bun 则是由 Oven 团队开发的执行环境。

事实上，Bun 除了作为 JavaScript 的执行环境，同时也能跑测试 (test runner)，也可以作为打包工具 (bundler)，像是 Webpack 或 Vite，同时能做为套件管理工具 (package manager) 像是 npm 或 Yan。简言之，是个一体成形，让你可以直接在上面用绝大多数开发 JavaScript 时要用的工具。

Bun 有什么特点? 解决 Node.js 什么问题?

Bun 的一大卖点是速度快。举例来说，Deno 每秒能处理的 React SSR 请求量是 Node.js 的两倍多，但是 Bun 更进一步做到能处理 Deno 两倍多的请求量 (也就是 Node.js 四倍多的请求量)。在 WebSocket 的讯息传递量，Bun 也是 Deno 的两倍多。在跟其他套件管理工具 (例如 npm 与 Yarn) 比，Bun 的套件安装速度超过十倍快。而在跑测试上，也比目前社群最快的 Vitest 还快不少。

除此之外，Bun 原生支援 TypeScript，让现在社群中多数人选择的 TypeScript，在使用上可以省去转译 (transpile)。在过去 Node.js，需要先把 TypeScript 转译成 JavaScript 后才能跑，Bun 原生支持就不需要额外转译，速度也就比较快。

速度之外，开发体验也是 Bun 的一大卖点。举例来说，Bun 的一个特点是，兼容 CommonJS 与 ESM，意即在 Bun 可以直接一起用这两者。换句话说，你可以同时用 import 与 require。假如有维护过又大又老的专案，会知道要把 CommonJS 搬移到 ESM 的痛苦程度不是一般。能兼容对许多人来说是一大福音。

另外，现在写 JavaScript 的一大痛点是有非常多的配置档案 (config files)。Bun 跟 Deno 一样，解决了这个痛点。因为原生支援 TypeScript 的关系，你不再需要 Babel 这类的转译工具配置；因为 Bun 本身是打包工具，你不需要 Webpack 这类工具 (现在社群有人开课专门在教 Webpack，换言之这东西本身不够简单，不然根本就不需要额外课程教人处理这些写程式以外的工具)。

甚至你也可以直接把 Bun 当成套件管理工具，就像是 pnpm、npm、yarn 那样，它的速度不仅更快，也让你不用有 package-lock.json 那类的档案。同时 Bun 本身可以跑测试，所以你也不用 Jest 或 Vitest，自然不用 jest.config.js 这类配置档案。总之这样数下来，用 Bun 时代码库可以少掉非常多让人烦恼的配置档案。

Bun 的未来发展值得看好吗?

一个好的工具到被大众采用，通常需要不少时间。现在还不明朗 Bun 是否能真的取代 Node.js 成为主流。但是 Bun 在与 Node.js 的兼容性上做得很好，这能大幅降低开发者从 Node.js 迁移到 Bun 的阻力。

当初 Deno 推出时，在 Node.js 的可兼容性上做得不是太好，这是有些想搬移到 Deno 的人会遇到的痛点。而 Bun 几乎做到 Node.js 的完全兼容 (除了少数几乎不会被人用的 Node.js 功能外)。所以你现在用 Node.js 的专案，直接拿 Bun 跑也完全没问题。

不得不说，Bun 绝对是值得观望的 JavaScript 新势力。