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 新勢力。