JavaScript 工具的未來將離 JavaScript 越來越遠，一些工具（如 Webpack 和 Babel）的重要性正在日益下降。為什么？

目前已經證明一些語言（如 Rust、Go 甚至 Zig）在捆綁、轉譯和編譯方面比 JavaScript 具有更好的性能。它們不是單線程的，這在處理大量文件方面具有優(yōu)勢。

是什么原因導致一定要用 JavaScript 開發(fā)生態(tài)系統(tǒng)的工具？畢竟這些工具主要運行在開發(fā)人員的機器上，而不是在瀏覽器上。此外，JavaScript 開發(fā)人員不需要調試這些工具的內部代碼。

SWC 是最早擺脫 JavaScript 的工具項目之一，不久之后，Esbuild 發(fā)布了，很多人為之興奮不已，因為在性能方面表現(xiàn)出色，它們成了真正的游戲規(guī)則改變者。目前，Vite 2.0 正在底層使用 Esbuild 來提供高性能的構建體驗。

最近，JavaScript 工具生態(tài)系統(tǒng)中出現(xiàn)了一個新成員——Bun。它的目標是讓整個 JavaScript 開發(fā)過程更加快速，這是一個全能的工具，它不僅加快了編譯和解析的速度，還提供了自己的依賴項管理器工具和捆綁。

這個工具還沒有為在生產環(huán)境中使用做好準備，但它的未來看起來很光明。本文將介紹這個新工具，以及它與 NPM、Esbuild、Babel 和 Webpack 之間的對比。

概覽

與其他使用 Rust 或 Go 開發(fā)的工具不同，Bun 是用 Zig 開發(fā)的。Zig 是一種通用的編程語言和工具鏈，用于開發(fā)和維護健壯、優(yōu)化和可重用的軟件。

盡管它是從頭開始開發(fā)的，但開發(fā)者采用了與 Esbuild 項目類似的開發(fā)方式。

Bun 支持一些開箱即用的復雜特性，如 TypeScript、CSS in Js、JSX，不過還缺少一些基本功能，如源映射、Minifier、搖樹優(yōu)化等。

Bun 的一個顯著特性是它提供了自己的 Node 模塊解析器實現(xiàn)，這是最值得關注的優(yōu)化之一。

與 NPM 和 Yarn 一樣，Bun 也會創(chuàng)建鎖文件，叫作 bun.lockb。這里需要注意的是，它生成的是二進制文件，而不是純文本文件。為什么是二進制文件？主要是出于性能的考慮。壞處是不便于我們檢查 PR 的變化。

檢查鎖文件的唯一方法是使用下面的命令：

bun install -y

Bun 目前支持下面這些加載器：

安裝配置

Bun 還不是一個公開項目，你需要加入他們的 Discord 頻道并發(fā)出邀請請求。在進入 Discord 后找到他們的 #invites 頻道，然后在“I want bun”頻道上發(fā)起邀請請求。

你將獲得一個一次性的 jarred-sumner/bun 代碼庫邀請。

要安裝 Bun，你需要執(zhí)行下面的命令：

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 版本。正如我前面提到的，它還沒有為在生產環(huán)境中使用做好準備。

使用

它的用法很簡單。如果你熟悉 Yarn 或 NPM，你會發(fā)現(xiàn)它們幾乎是一樣的。

安裝包：

bun install

與 Yarn 一樣，它將使用已有的 package.json 與鎖文件（如果有的話）的組合。

添加或刪除包：

bun remove react
bun add preact

我們可以將 Bun 作為執(zhí)行器：

# instead of `npm run clean`
bun run clean
# if added to the `scripts` in package.json
bun clean

它通過 create 命令提供了與最新的 React 生態(tài)系統(tǒng)的一些集成。

我們來創(chuàng)建一個 Next.js 應用：

bun create next ./app
cd app
bun

我們來創(chuàng)建一個 Create-React 應用：

bun create react ./app
cd app
bun

如何生成捆綁文件？

運行bun bun ./path-to.js可以生成 node_modules.bun 文件，它包含了所有導入的依賴項。

你可以通過執(zhí)行./node_modules.bun > build.js來查看包的內容。

基準測試

讓我們通過運行一些基準測試來了解它的速度。當然，這些都是近似的測量值，并且跟運行環(huán)境的配置有關。因為這是開發(fā)人員的工具，所以我主要關注最常見的開發(fā)任務：

• 啟動開發(fā)服務器；
• 對文件做一些修改；
• 安裝包；
• 構建生產發(fā)行包；
• 創(chuàng)建一個新的 Web 應用程序。

作為參考，我的筆記本電腦配備了 AMD Raizen 7 CPU 和 16GB 內存，系統(tǒng)是 Ubuntu 20.04。

我使用了一個生成隨機 jsx 文件的工具。我生成了 21 個隨機的 jsx 文件，我將它們包含在所有測試項目中。

Bun 與 Babel

這個對比可能不是很公平，但它確實讓我們看到這個工具與傳統(tǒng)工具相比是多么的快。

轉譯 React 文件對比

創(chuàng)建一個 Create-React 應用

我們可以看到，使用 Bun 和 Webpack+NPM 創(chuàng)建 Create React 應用之間的明顯區(qū)別。前者幾乎沒有任何延遲，只需要 4.4 秒就可以完成所有設置。

創(chuàng)建 CRA 對比

創(chuàng)建一個 Next.js 應用

之前的結果其實并沒有那么令人印象深刻，畢竟我們已經習慣了用其他工具痛擊 Webpack。我們來進行一場公平的戰(zhàn)斗，比較一下 Bun 和 SWC。

Bun 與 SWC 對比

兩者之間的差異非常明顯，特別是在處理文件變更方面。在我的筆記本電腦上，Bun 只需要 10 毫秒，而 SWC 需要 70 毫秒。

包管理器

在模塊的安裝和操作方面，Bun 也有一些優(yōu)勢。其他工具依賴 NPM 或 Yarn 來完成這項工作，Bun 的性能大約比 NPM 快 4 到 100 倍。

我們已經第二步中看到了兩者的巨大差異。不過，我們現(xiàn)在來做一個更基本的例子。我們創(chuàng)建一個 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 在開發(fā)服務器方面的對比

我還基于之前相同的代碼使用三個主要工具生成了捆綁包。需要注意的是，我們不建議在生產環(huán)境中使用 Bun，因為它缺少了相當多的特性。盡管基準測試結果令人印象深刻，但我們還是要持謹慎的態(tài)度。

在最壞的情況下，最長構建時間是 7 秒。這三個工具在這方面做得很出色，不是沒有道理的。

Bun、Vite、SWC 構建一個用于生產環(huán)境的捆綁包。

總結

JavaScript 工具從未像現(xiàn)在這么好過，即使這個工具還沒有為在生產環(huán)境中使用做好準備，但出現(xiàn)了新的競爭對手總是一件好事。Webpack 的未來還不明朗，它在 JavaScript 領域內外都有很多競爭對手。

Bun 并不是萬能的工具，它擅長的是構建網站和 Web 應用。如果要構建庫，Bun 團隊建議使用 Esbuild，甚至 Rollup。

現(xiàn)在，Bun 開發(fā)團隊的重心仍然不在生產就緒方面，他們專注于開發(fā)以及與現(xiàn)有框架和工具的兼容性。