厭倦 JavaScript，開發者用 Rust 開啟替換潮？

關注「 Rust程式設計指北 」，一起學習 Rust，給未來投資

作者 | Lee Robinson

譯者 | 彎月

出品 | CSDN（ID：CSDNnews）

Rust 是一種快速、可靠且記憶體使用效率非常高的程式語言，連續六年被評為最受歡迎的程式語言。Rust 由 Mozilla 建立，現已被 Facebook、蘋果、亞馬遜、微軟和 Google 等科技大公司用於系統基礎設施、加密、虛擬化以及其他底層 的開發。

為什麼如今人們利用 Rust 來替換 JavaScript 網路生態系統中的一些工具，比如壓縮器（Terser）、轉譯（Babel）、格式化（Prettier）、打包（webpack）、linting （ESLint） 等等？

1

Rust 是什麼？

Rust 是一種可幫助開發人員編寫高效使用記憶體的快速程式語言。它是可以替代 C++ 或 C 等的現代程式語言，注重程式碼的安全和簡潔的語法。

Rust 與 JavaScript 完全不同。JavaScript 會設法查詢未使用的變數或物件，並自動從記憶體中清除，也就是我們常說的垃圾收集。因此，JavaScript 開發人員無需考慮手動記憶體管理。

然而，Rust 開發人員可以更好地控制記憶體分配，同時又不會像 C++ 或 Go 那樣痛苦。

Rust 使用了一種相對獨特的記憶體管理方法，它吸收了記憶體“所有權”的思想。大致來說，Rust 會跟蹤誰可以讀寫記憶體。它知道程式何時使用記憶體，並在不再需要時立即釋放記憶體。它會在編譯時強制檢查有關記憶體的規則，因此執行時幾乎不可能出現記憶體錯誤。開發人員無需手動跟蹤記憶體，編譯器會自動處理。

—— Discord

2

採用

除了上面提到的公司之外，Rust 還被廣泛用於流行的開源庫，例如：

• Firecracker (AWS)

• Bottlerocket (AWS)

• Quiche (Cloudflare)

• Neqo (Mozilla)

Rust 使得我們團隊事半功倍，採用 Rust 是我們做出的最佳決策之一。Rust 的優勢不僅限於效能，而且還可以提高我們的效率，Rust 注重正確性，幫助我們解決了同步操作的複雜性。我們將系統複雜的不變數編碼到型別系統中，並讓編譯器幫我們進行檢查。

—— Dropbox

3

從 JavaScript 到 Rust

JavaScript 是一種使用極其廣泛的程式語言，可在所有帶有 Web 瀏覽器的裝置上執行。在過去的十年中，人們圍繞 JavaScript 構建了一個龐大的生態系統：

• Webpack：開發人員希望將多個 JavaScript 檔案打包成一個。

• Babel：開發人員希望支援舊瀏覽器，同時還能編寫現代 JavaScript。

• Terser：開發人員希望儘量壓縮生成的檔案大小。

• Prettier：開發人員想要一個可自行決定的程式碼格式化程式。

• ESLint：開發人員希望在部署之前發現程式碼中的問題。

人們編寫了數百萬行 JavaScript 程式碼，修復了大量 bug，為當今 Web 應用程式的開發奠定了基礎。所有這些工具都是用 JavaScript 或 TypeScript 編寫的。雖然這些工作非常了不起，但利用 JavaScript 實現的優化已經達到了極限。因此，人們渴望一類新工具的出現，並大幅提高 Web 構建的效能。

4

SWC

SWC 創建於 2017 年，是一個基於 Rust 的可擴充套件平臺，旨在構建下一代的開發工具。Next.js、Parcel 和Deno 等工具以及 Vercel、位元組跳動、騰訊、Shopify等公司都在使用該平臺。

SWC 可作為編譯、壓縮、打包等工具，而且功能還在不斷擴充套件。開發人員可以用它來執行程式碼轉換（內建或自定義轉換），這些轉換都是通過 Next.js 等更高級別的工具進行的。

5

Deno

Deno 創建於 2018 年，是一個簡單、現代且安全的 JavaScript 和 TypeScript 執行時，是使用 V8 引擎和 Rust 構建的。Deno 由Node.js 的原作者編寫，目標是取代 Node.js。雖然該執行時於 2018 年建立，但直到 2020 年5 月才發行第一版。

Deno 的 linter、程式碼格式化程式和文件生成器都是使用 SWC 構建的。

6

esbuild

esbuild 創建於 2020 年 1 月，是一款JavaScript 打包器和壓縮器，比使用 Go 編寫的現有工具快 10～100 倍。

我在嘗試建立一個構建工具，主要目標有兩個：第一，打包 JavaScript、TypeScript 和 CSS；第二，向社群展示超快速的 JavaScript 構建工具。在我看來，目前的構建工具實在太慢了。

——Evan，esbuild 的建立者

在 esbuild 釋出之前，使用 Go 和 Rust 等系統程式語言構建 JavaScript 工具的做法非常小眾。我認為，esbuild 激發了更廣泛的興趣，人們紛紛開始嘗試構建快速的開發工具。Evan 選擇使用 Go，原因在於：

如果付出足夠的努力，Rust 版本也可以達到非常快的執行速度。但從高層來看，使用 Go 更有趣。由於這是一個業餘專案，因此我希望享受一定的樂趣。

——Evan，esbuild 的建立者

有人認為 Rust 的效能更好，但這兩種語言都可以實現 Evan 影響社群的最初目標：

只需基本的優化，Rust 的效能就會遠超手動調整的 Go 程式碼。使用 Rust 編寫高效的程式非常容易，而使用 Go 則必須非常深入地研究。

—— Discord

7

Rome

Rome 於 2020 年 8 月建立，是一個面向 JavaScript、TypeScript、HTML、JSON、Markdown 和 CSS 的 linter、編譯器、打包器、測試執行器。主要目標是替換和統一整個前端開發的工具鏈。這款工具由 Sebastian 建立的，另外 Sebastian 還建立了 Babel。

為什麼要重新編寫呢？

如果想對 Babel 進行必要的修改，使其成為其他工具的堅實基礎，則必須重寫所有程式碼。這個架構來源於我在 2014 年學習解析器、AST 和編譯器時做出的設計選擇。

—— Sebastian

目前，Rome 是用 TypeScript 編寫並在 Node.js 上執行。但他們正在用 Rust 重寫。

8

Rust + WebAssembly

WebAssembly（WASM）是一種可移植的底層語言，而 Rust 可以編譯成 WASM。WASM在瀏覽器中執行，可與 JavaScript 互操作，如今所有的主流現代瀏覽器都支援 WASM。

WASM的速度遠比 JS 快，但不及原生應用。根據我們的測試，如果將 Parcel 編譯為 WASM，則執行速度比原生應用慢 10～20 倍。

—— Devon Govett

雖然 WASM 還不是完美的解決方案，但可以幫助開發人員創建極快的 Web 體驗。如今，Rust 團隊正在努力構建高質量且最尖端的 WASM 實現。這意味著，開發人員可以使用 WASM 編譯 Web 應用，同時還可以享受 Rust 的效能優勢。

該領域已浮現出一些早期的庫和框架：

• Yew

• Percy

• Seed

• Sycamore

• Stork

這些基於 Rust 的 Web 框架都編譯成了WASM，但它們的目標不是取代 JavaScript，而是與JavaScript 協同工作。現如今 Rust 正在朝著兩個方向努力：加快現有 JavaScript 工具的執行速度；將 Web 應用編譯成 WASM。

一路討論下來，我們看到的都是 Rust。

9

Rust 的缺點

Rust 的學習曲線很陡峭，抽象級別更靠近底層，超過了大多數 Web 開發人員所掌握的水平。

Rust使我們思考關係到系統程式設計的程式碼維度。讓我們思考如何共享或複製記憶體。讓我們思考真實但不太可能出現的極端情況，並確保這些情況都能得到恰當的處理。Rust 可以幫助我們編寫無論從何種角度來看都非常高效的程式碼。

—— Tom MacWright  

此外，Rust 在網路社群中的使用仍然很小眾。採用率並不高。儘管為了 JavaScript 的工具而學習 Rust 是一個入門障礙，但有趣的是，即便某個工具的程式碼不是很熟悉，但只要速度非常快就能贏得開發人員的青睞。速度制勝。

目前，有些服務很難找到相應的 Rust 庫或框架，比如身份驗證、資料庫、支付等。但我認為，隨著 Rust 和 WASM 的採用率上升，這些問題自然就能得到解決。然而，目前還沒有達到這個水平。我們需要利用現有的 JavaScript 工具，幫助我們彌合差距，並逐步享受效能的提升。

10

JavaScript 工具的未來

我相信 Rust 是 JavaScript 工具的未來。從 Next.js 12 開始，我們逐步開始過渡，用 SWC 和 Rust 取代 Babel（轉譯）和Terser（壓縮）。為什麼？

• 可擴充套件性：SWC 可以作為一個 crate 在 Next.js 中使用，無需建立分叉庫，也無需繞開設計約束。

• 效能：換成 SWC，就能夠將 Next.js 的快速重新整理提高約 3 倍，構建速度提高約 5 倍，此外還有更多優化仍在開發中。

• WebAssembly：Rust 對 WASM 的支援成為了支援所有平臺和推廣 Next.js 開發的關鍵。

• 社群：Rust 社群和生態系統非常優秀，且在不斷增長中。

採用 SWC 的不僅限於 Next.js，還有：

• Deno 的 linter、程式碼格式化程式和文件生成器都是使用 SWC 構建的。

• Rome 正在用 Rust 重寫，並計劃使用 SWC。

• dprint 是使用 SWC 構建的，這款程式碼格式化工具的速度是 Prettier 的 30倍。

• Parcel 使用 SWC 將整體構建效能提高了 10 倍。

Parcel將 SWC 作為一個庫使用。以前我們使用 Babel 的解析器和用 JS 編寫的自定義轉換。現在，我們使用 SWC 的解析器和 Rust 的自定義轉換。這項工作包括全部的 hoisting 實現、依賴項集合等。涉及範圍之廣類似於在 SWC 之上構建 Deno。

—— Devon Govett

目前，Rust 還處於早期階段，一些重要的功能尚在研究中：

• 外掛：對於許多 JavaScript 開發人員來說，用 Rust 編寫外掛並不容易。同時，公開 JavaScript 的外掛系統可能會導致效能的提升蕩然無存。最終的解決方案尚未出現。

• 打包：swcpack是一個有趣的開發領域，SWC 利用它來代替 Webpack。這款工具仍在開發中，但前景非常看好。

• WebAssembly：如上所述，編寫Rust 程式碼並編譯成 WASM 的前景很誘人，但仍有很多工作需要努力。

總的來說，我相信在未來 1～2 年內 Rust 將對 JavaScript 生態系統產生重大影響。想象一下，Next.js 中使用的所有構建工具都是用 Rust 編寫的，這樣就能為你提供極致的效能。此外，Next.js 還可以作為靜態二進位制檔案通過 NPM 下載。

我心目中理想的開發世界，不外乎與此。

11

評論

對此，網友也發表了不同的看法：

評論1

回想當初寫下第一行 JavaScript 程式碼，已經過去16年了，然而至今我仍然對這門語言深惡痛絕。JavaScript 是那麼神祕莫測，在使用 TypeScript 的時候這種感覺有過之而無不及。瀏覽器不相容的問題仍然很普遍（雖然不像以前那麼痛苦）。流行的庫也常常沒有任何文件，我不得不到處搜尋。遇到有些問題時，我遍尋無果，直到有一天看到 GitHub 上的某個議題，才解開了痛苦之源。更重要的是，每天都有人在為構建流水線新增更多令人困惑而又不透明的工具。各色的打包器、載入器、編譯器、轉譯器以及平臺等等各自為政，讓人眼花繚亂。

因此，我非常渴望有一天能夠完全擺脫 JavaScript，換成某個更健全的語言，更完善的構建工具。

評論2

JavaScript 看上去像是人們僅花了 10 天做出來的東西，目的僅僅是為了填補 HTML 缺乏的互動性。如果 Brendan Eich 知道人們今天如此使用 JavaScript，這門語言肯定會以完全不同的面貌出現。

評論3

我很高興看到 JavaScript 的工具遵循了能用=>好用=>速度快的發展過程，這才是構建軟體的正確方向。如果一開始就以速度快為目標，那肯定不會有現在的百花齊放的局面。

參考連結：

http://leerob.io/blog/rust

推薦閱讀

• Rust 會成為 JavaScript 基礎設施的未來嗎？

覺得不錯，點個贊吧

掃碼關注「 Rust程式設計指北 」