Bun 會是 Webpack 之后的下一件大事嗎？
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 -y
Bun 目前支持下面這些加載器：
安裝配置
Bun 還不是一個公開項目，你需要加入他們的 Discord 頻道并發出邀請請求。在進入 Discord 后找到他們的 #invites 頻道，然后在“I want bun”頻道上發起邀請請求。
你將獲得一個一次性的 jarred-sumner/bun 代碼庫邀請。
要安裝 Bun，你需要執行下面的命令：
curl -fsSL https://bun.sh/install | bash
# Manually add the directory to your $HOME/.bashrc (or similar)
BUN_INSTALL="/home/jgranja/.bun"
PATH="$BUN_INSTALL/bin:$PATH"
檢查是否可以正常運行：
bun --version
你會看到它還沒有達到 1.0.0 版本。正如我前面提到的，它還沒有為在生產環境中使用做好準備。
使用
它的用法很簡單。如果你熟悉 Yarn 或 NPM，你會發現它們幾乎是一樣的。
安裝包：
bun install
與 Yarn 一樣，它將使用已有的 package.json 與鎖文件（如果有的話）的組合。
添加或刪除包：
bun remove react
bun add preact
我們可以將 Bun 作為執行器：
# instead of `npm run clean`
bun run clean
# if added to the `scripts` in package.json
bun clean
它通過 create 命令提供了與最新的 React 生態系統的一些集成。
我們來創建一個 Next.js 應用：
bun create next ./app
cd app
bun
我們來創建一個 Create-React 應用：
bun create react ./app
cd app
bun
如何生成捆綁文件？
運行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
這個對比可能不是很公平，但它確實讓我們看到這個工具與傳統工具相比是多么的快。
轉譯 React 文件對比
創建一個 Create-React 應用
我們可以看到，使用 Bun 和 Webpack+NPM 創建 Create React 應用之間的明顯區別。前者幾乎沒有任何延遲，只需要 4.4 秒就可以完成所有設置。
創建 CRA 對比
創建一個 Next.js 應用
之前的結果其實并沒有那么令人印象深刻，畢竟我們已經習慣了用其他工具痛擊 Webpack。我們來進行一場公平的戰斗，比較一下 Bun 和 SWC。
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）。
Bun 與 NPM 安裝包對比
時間差異很明顯。如果通過網絡安裝，速度快 4 倍，如果從緩存中解析，速度會快更多。
Bun 與 Vite
Esbuild 是 Bun 真正的競爭對手。對于這個測試，我使用了 Vite，因為它內部使用了 Esbuild。
Bun 與 Vite 在開發服務器方面的對比
我還基于之前相同的代碼使用三個主要工具生成了捆綁包。需要注意的是，我們不建議在生產環境中使用 Bun，因為它缺少了相當多的特性。盡管基準測試結果令人印象深刻，但我們還是要持謹慎的態度。
在最壞的情況下，最長構建時間是 7 秒。這三個工具在這方面做得很出色，不是沒有道理的。
Bun、Vite、SWC 構建一個用于生產環境的捆綁包。
總結
JavaScript 工具從未像現在這么好過，即使這個工具還沒有為在生產環境中使用做好準備，但出現了新的競爭對手總是一件好事。Webpack 的未來還不明朗，它在 JavaScript 領域內外都有很多競爭對手。
Bun 并不是萬能的工具，它擅長的是構建網站和 Web 應用。如果要構建庫，Bun 團隊建議使用 Esbuild，甚至 Rollup。
現在，Bun 開發團隊的重心仍然不在生產就緒方面，他們專注于開發以及與現有框架和工具的兼容性。
