Bun 是否能挑戰(zhàn) Webpack、Vite 的霸主地位 ？

作者丨 Jose Granja
譯者丨明知山
策劃丨閆園園
JavaScript 工具的未來(lái)將離 JavaScript 越來(lái)越遠(yuǎn)，一些工具（如 Webpack 和 Babel）的重要性正在日益下降。為什么？

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

是什么原因?qū)е乱欢ㄒ?JavaScript 開(kāi)發(fā)生態(tài)系統(tǒng)的工具？畢竟這些工具主要運(yùn)行在開(kāi)發(fā)人員的機(jī)器上，而不是在瀏覽器上。此外，JavaScript 開(kāi)發(fā)人員不需要調(diào)試這些工具的內(nèi)部代碼。

SWC 是最早擺脫 JavaScript 的工具項(xiàng)目之一，不久之后，Esbuild 發(fā)布了，很多人為之興奮不已，因?yàn)樵谛阅芊矫姹憩F(xiàn)出色，它們成了真正的游戲規(guī)則改變者。目前，Vite 2.0 正在底層使用 Esbuild 來(lái)提供高性能的構(gòu)建體驗(yàn)。

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

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

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

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

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

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

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

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

bun install -y
Bun 目前支持下面這些加載器：



安裝配置
Bun 還不是一個(gè)公開(kāi)項(xiàng)目，你需要加入他們的 Discord 頻道并發(fā)出邀請(qǐng)請(qǐng)求。在進(jìn)入 Discord 后找到他們的 #invites 頻道，然后在“I want bun”頻道上發(fā)起邀請(qǐng)請(qǐng)求。

你將獲得一個(gè)一次性的 jarred-sumner/bun 代碼庫(kù)邀請(qǐng)。

要安裝 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"
檢查是否可以正常運(yùn)行：

bun --version
你會(huì)看到它還沒(méi)有達(dá)到 1.0.0 版本。正如我前面提到的，它還沒(méi)有為在生產(chǎn)環(huán)境中使用做好準(zhǔn)備。

使用
它的用法很簡(jiǎn)單。如果你熟悉 Yarn 或 NPM，你會(huì)發(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
它通過(guò) create 命令提供了與最新的 React 生態(tài)系統(tǒng)的一些集成。

我們來(lái)創(chuàng)建一個(gè) Next.js 應(yīng)用：

bun create next ./app
cd app
bun
我們來(lái)創(chuàng)建一個(gè) Create-React 應(yīng)用：

bun create react ./app
cd app
bun
如何生成捆綁文件？

運(yùn)行bun bun ./path-to.js可以生成 node_modules.bun 文件，它包含了所有導(dǎo)入的依賴項(xiàng)。

你可以通過(guò)執(zhí)行./node_modules.bun > build.js來(lái)查看包的內(nèi)容。

基準(zhǔn)測(cè)試
讓我們通過(guò)運(yùn)行一些基準(zhǔn)測(cè)試來(lái)了解它的速度。當(dāng)然，這些都是近似的測(cè)量值，并且跟運(yùn)行環(huán)境的配置有關(guān)。因?yàn)檫@是開(kāi)發(fā)人員的工具，所以我主要關(guān)注最常見(jiàn)的開(kāi)發(fā)任務(wù)：

啟動(dòng)開(kāi)發(fā)服務(wù)器；

對(duì)文件做一些修改；

安裝包；

構(gòu)建生產(chǎn)發(fā)行包；

創(chuàng)建一個(gè)新的 Web 應(yīng)用程序。






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

我使用了一個(gè)生成隨機(jī) jsx 文件的工具。我生成了 21 個(gè)隨機(jī)的 jsx 文件，我將它們包含在所有測(cè)試項(xiàng)目中。

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



轉(zhuǎn)譯 React 文件對(duì)比

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



創(chuàng)建 CRA 對(duì)比

創(chuàng)建一個(gè) Next.js 應(yīng)用
之前的結(jié)果其實(shí)并沒(méi)有那么令人印象深刻，畢竟我們已經(jīng)習(xí)慣了用其他工具痛擊 Webpack。我們來(lái)進(jìn)行一場(chǎng)公平的戰(zhàn)斗，比較一下 Bun 和 SWC。



Bun 與 SWC 對(duì)比

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

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

我們已經(jīng)第二步中看到了兩者的巨大差異。不過(guò)，我們現(xiàn)在來(lái)做一個(gè)更基本的例子。我們創(chuàng)建一個(gè) package.json 文件，其中的依賴項(xiàng)如下：

date-fns@2.28.0——89.5KB

jspdf@2.5.1——339.1KB

react@17.0.2——6.9KB

然后我們對(duì)第一次安裝和基于緩存安裝進(jìn)行基準(zhǔn)測(cè)試。為了讓差異更加明顯，我選擇了一個(gè)大型的庫(kù)（jspdf）。



Bun 與 NPM 安裝包對(duì)比

時(shí)間差異很明顯。如果通過(guò)網(wǎng)絡(luò)安裝，速度快 4 倍，如果從緩存中解析，速度會(huì)快更多。

Bun 與 Vite
Esbuild 是 Bun 真正的競(jìng)爭(zhēng)對(duì)手。對(duì)于這個(gè)測(cè)試，我使用了 Vite，因?yàn)樗鼉?nèi)部使用了 Esbuild。



Bun 與 Vite 在開(kāi)發(fā)服務(wù)器方面的對(duì)比

我還基于之前相同的代碼使用三個(gè)主要工具生成了捆綁包。需要注意的是，我們不建議在生產(chǎn)環(huán)境中使用 Bun，因?yàn)樗鄙倭讼喈?dāng)多的特性。盡管基準(zhǔn)測(cè)試結(jié)果令人印象深刻，但我們還是要持謹(jǐn)慎的態(tài)度。

在最壞的情況下，最長(zhǎng)構(gòu)建時(shí)間是 7 秒。這三個(gè)工具在這方面做得很出色，不是沒(méi)有道理的。



Bun、Vite、SWC 構(gòu)建一個(gè)用于生產(chǎn)環(huán)境的捆綁包

總結(jié)
JavaScript 工具從未像現(xiàn)在這么好過(guò)，即使這個(gè)工具還沒(méi)有為在生產(chǎn)環(huán)境中使用做好準(zhǔn)備，但出現(xiàn)了新的競(jìng)爭(zhēng)對(duì)手總是一件好事。Webpack 的未來(lái)還不明朗，它在 JavaScript 領(lǐng)域內(nèi)外都有很多競(jìng)爭(zhēng)對(duì)手。

Bun 并不是萬(wàn)能的工具，它擅長(zhǎng)的是構(gòu)建網(wǎng)站和 Web 應(yīng)用。如果要構(gòu)建庫(kù)，Bun 團(tuán)隊(duì)建議使用 Esbuild，甚至 Rollup。

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

原文鏈接：

https://betterprogramming.pub/is-bun-the-next-big-thing-after-webpack-d683441f77b9

作者：Jose Granja


歡迎關(guān)注微信公眾號(hào) ：前端開(kāi)發(fā)愛(ài)好者


添加好友備注【進(jìn)階學(xué)習(xí)】拉你進(jìn)技術(shù)交流群