大家好，我是三元同學。

隨著前端技術(shù)棧的發(fā)展，Rust 作為一門系統(tǒng)級語言，也逐漸進入了前端開發(fā)者的視野。最近很明顯的一個例子就是，今年的 ViteConf 中尤雨溪宣布 Vite 的底層即將用 Rust 重寫，即開發(fā)一個基于 Rust 的打包工具 Rolldown，以此替換掉原有的 Esbuild 和 Rollup。當這個消息傳出后，不少前端開發(fā)者開始關(guān)注起了 Rust，也陸續(xù)有不少的讀者朋友問我相同的問題：作為一個前端，我有必要學 Rust 嗎？

首先給出我的回答：作為一個前端，你沒有必要學 Rust。當然，這并不是說 Rust 對于前端開發(fā)者沒有任何價值，而是說 Rust 并不是前端開發(fā)者必須要學習的技術(shù)。為什么這么說？接下來我來跟大家詳細聊聊。

Rust 在前端做些什么

不可否認的是，Rust 作為一門現(xiàn)代化的系統(tǒng)級編程語言，本身有著很多優(yōu)勢，比如它的內(nèi)存安全、并發(fā)安全、現(xiàn)代化的工程化能力(如包管理)，這些優(yōu)勢使得 Rust 在如今的操作系統(tǒng)、云計算、區(qū)塊鏈等等領(lǐng)域都有著越來越多的應(yīng)用。而在前端領(lǐng)域，Rust 也有著自己的一席之地。

Vercel（Next.js 背后的公司）的 CEO Lee Robinson 老哥在兩年前寫過一篇文章——《Rust 是前端基建的未來》。

原文鏈接：https://leerob.io/blog/rust

他在這篇文章中指出了以下的幾個基建方向會被 Rust 所顛覆：

• webpack。即底層構(gòu)建工具層。
• Babel。即 JavaScript 編譯器。
• ESLint。即代碼檢查器。
• Prettier。即代碼格式化工具。
• Terser。即代碼壓縮器。

而到如今 2023 年，兩年過去了，這個判斷也越來越接近現(xiàn)實。我們不妨來看看這些年 Rust 在前端做了些什么。

構(gòu)建工具

首先是構(gòu)建工具。在前端領(lǐng)域，構(gòu)建工具的重要性想必不用多說，而在 2022 年 10 月底，Next.js 首先推出了第一款基于 Rust 的構(gòu)建工具 Turbopack，當時引起了一時的轟動，一方面確實是因為它的性能數(shù)據(jù)確實很驚艷，號稱比 Vite 快十倍，另一方面，Vite 的作者尤雨溪對此表示了質(zhì)疑：真的比 Vite 快 10 倍嗎？于是創(chuàng)建了一個 Issue，附上了自己測出來的性能數(shù)據(jù)，有理有據(jù)，吸引不少人前來學(chi)習(gua)。這個事件屬實讓 Turbopack 的熱度更加高漲。

但好景不長，由于本身的一些問題，比如不支持插件機制、和 Next.js 綁定太死，后來就一直不溫不火了。

Turbopack 某種程度上也許讓我們對 Rust 構(gòu)建工具感到失望，當時我在某乎上表達了自己失望的原因。

回答鏈接：https://www.zhihu.com/people/yang-xing-yuan-9/answers

時間來到了 2023 年 3 月 10 號，字節(jié)跳動 Web Infra 團隊正式宣布發(fā)布了 Rspack:

Rspack 的出現(xiàn)，讓我們再次看到了 Rust 構(gòu)建工具的希望。在此我想強調(diào)的點并不是性能，畢竟 Rust 造的工具動不動快個 5 倍 10 倍 100 倍的，大家早就看的索然無味了，不是嗎？我想強調(diào)的是產(chǎn)品上的可落地，我們見了太多的玩具，請讓我們看到一個可以落地到生產(chǎn)環(huán)境的 Rust 構(gòu)建工具。毫不夸張的說，Rspack 的出現(xiàn)證明了這一點。為什么這么說？

我們不妨先從反面來思考，基于 Rust 的構(gòu)建工具為什么難以落地：

• 現(xiàn)有項目基于都是 webpack 的，怎么遷移？
• 現(xiàn)有的 webpack 生態(tài)中，里面的 loader 和 plugin 都是 JS 寫的，在 Rust 構(gòu)建工具中用不了，怎么辦？
• 工具是 Rust 寫的，如果我要寫一些 loader 和 plugin，我不會 Rust，怎么辦？

總結(jié)起來就是三個問題：

• 遷移成本高
• 生態(tài)不完善
• 擴展門檻高

而 Rspack 的出現(xiàn)，恰恰很好解決了這三個問題：

• 配置幾乎跟 webpack 一模一樣，連插件和 loader 的 API 也基本相同，這使得現(xiàn)有的 webpack 項目遷移成本非常低。
• Rspack 支持 JS 編寫 loader 和 plugin（感興趣的可以看看 napi-rs)，這意味著大部分的 webpack 生態(tài)可以直接復(fù)用，這使得 Rspack 生態(tài)有非常好的開端。
• 也正是由于 Rspack 支持 JS 編寫 loader 和 plugin，這使得擴展門檻非常低，你不會 Rust 也可以寫 loader 和 plugin，直接用 JS 就可以開發(fā)。

到如今，Rspack 在業(yè)界已經(jīng)有了相當大的影響力了，不少的國外知名項目，比如 Discord 、 NetLify 等等，都已經(jīng)接入 Rspack，并且獲得了 5~10 倍的性能提升。前不久，《現(xiàn)代 JavaScript 庫開發(fā)：原理、技術(shù)與實戰(zhàn)》作者顏海鏡老哥也將團隊的巨型項目(50w 行代碼)從 webpack 遷移到了 Rspack，獲得了 10 倍以上的性能收益，不禁要為 Rspack "代顏"：

Rspack 的出現(xiàn)，讓我們能夠看到了 Rust 前端構(gòu)建工具這個賽道的可行性，基于 Rust 的構(gòu)建工具，原來也可以低成本地落地到生產(chǎn)環(huán)境，也可以非常"接地氣"。

編譯器

接下來就是編譯器，我們可以分為兩部分來看：JavaScript 編譯器和 CSS 編譯器。

對于前者而言，我們比較耳熟能詳?shù)木褪?Babel 了。Babel 作為一個 JavaScript 編譯器，它的重要性不言而喻，它的出現(xiàn)，讓我們可以使用 ES6+ 的語法，而不用擔心兼容性問題。然而隨著項目規(guī)模的擴大，Babel 的性能問題也逐漸暴露出來，隨后基于 Rust 的 JavaScript 編譯器 SWC 也應(yīng)運而生。

官方數(shù)據(jù)顯示，SWC 的性能在單核機器上比 Babel 快 20 倍，而在多核機器上比 Babel 快 70 倍，相當驚人。

除了 SWC 之外，還有基于 Rust 的 JavaScript 編譯器 Oxc，也非常來勢洶洶，官方對比數(shù)據(jù)顯示，它比 SWC 的性能還要再快個一倍左右！這個項目也是由字節(jié)的 Web Infra 團隊開發(fā)的，目前功能有待完善，不過是一個值得關(guān)注的項目。

倉庫地址：https://github.com/web-infra-dev/oxc

接下來是 CSS 編譯器了，這個領(lǐng)域當中Lightning CSS 可以說一騎絕塵，它的性能比原有的 JS 開發(fā)的 CSS 工具鏈快了 100 多倍！

官網(wǎng)：https://lightningcss.dev/

代碼檢查器

ESLint 是目前前端工程中非常常用的一個工具，它可以幫助我們檢查代碼中的潛在問題，比如變量未使用、函數(shù)未使用、變量未定義等等。ESLint 本身是基于 JavaScript 開發(fā)的，但是它的性能一直是個問題，隨著項目規(guī)模的擴大，ESLint 的性能問題也逐漸暴露出來。因此近幾年誕生了基于 Rust 的 Lint 工具 OxcLint。

還記得上文中介紹的 Oxc 嗎？OxcLint 就是基于 Oxc 開發(fā)的，而且 OxcLint 的性能比 ESLint 快了 50 倍以上。

文檔框架

大家平時如果要快速搭建一個文檔站點、博客站點或者產(chǎn)品的主頁，可能會選擇 Docusaurus、VuePress、VitePress 等等，社區(qū)的這些框架確實可以很方便的幫助我們快速搭建一個文檔站點，但這些框架的性能卻成為了一個問題，基于 Vite 的 VitePress 雖然借助 Vite 在開發(fā)階段的優(yōu)勢可以快速啟動，但在生產(chǎn)環(huán)境下，不得不使用 Rollup 打包，仍然”不夠快“。

而在這個領(lǐng)域，我們又有了一個新的選擇：Rspress。這個框架中也有相當多的 Rust 成分，比如基于 Rspack 進行構(gòu)建、基于 Rust 編寫的 Markdown 編譯器，并且最終的性能也是很不錯的，基本能在一秒內(nèi)啟動項目：

感興趣的朋友們不妨可以去了解一下。

Rspress 官網(wǎng)地址：https://rspress.dev

倉庫地址：https://github.com/web-infra-dev/rspress

術(shù)業(yè)有專攻

好，以上我們介紹了這么多 Rust 在前端領(lǐng)域的應(yīng)用，那么我們不妨追問一句：到底是誰在寫這些東西呢？

如果我們將這些人簡單定義為前端開發(fā)者，那就有些不太負責任了。更準確地來說，Rust 前端工具應(yīng)該屬于前端工程化基建的范疇，而這些工具的開發(fā)者，應(yīng)該叫做基建工程師。工程化是前端領(lǐng)域的一個垂直方向，就跟可視化、前端安全一樣。而這個領(lǐng)域，并不需要每個前端開發(fā)者的參與，一般來說只需要少量的人去做就可以了。而之所以對于 Rust 化工具鏈這件事情大家會有這么多的關(guān)注，是因為這些工具和我們的日常開發(fā)息息相關(guān)，我們每天都在使用，所以才會有這么多的關(guān)注。但實際上我們必須要投入大量的精力去學習如何開發(fā)這些工具嗎？顯然不是，大部分人只需要會用就可以了，有余力的情況下了解一些原理即可。

從另外一個角度來說，如果提供工具的人，把一個工具的使用方法做的非常復(fù)雜，比如需要你要掌握 Rust 這門新語言才能寫插件，那說明工具的設(shè)計本身就是有問題的。一個好的工具，本質(zhì)上是在有限的條件下盡可能地降低使用門檻，而不是為了達到另外一些目的而提高使用門檻。

作為前端，我要學 Rust 嗎?

介紹了這么多，讓我們回到最初的問題：作為一個前端開發(fā)者，我要學 Rust 嗎？

現(xiàn)在你可以反問自己一個更本質(zhì)的問題：你為什么要學一門技術(shù)？不僅僅是 Rust，你可以把這個客體換成任何一門技術(shù)，比如 Vue、React、Flutter、跨端、SolidJS、ChatGPT 等等。

• 是因為它有趣嗎？
• 是因為它能夠幫助你解決實際問題嗎？
• 是因為它能夠幫助你更容易通過面試和升職嗎？
• 還是因為，大家都在談?wù)摚晕乙惨獙W？

我想不同的人給出的答案也許是不同的。

如果你覺得 Rust 很有趣，那么事實上任何你覺得有趣的技術(shù)，你都可以去學習，能夠找到自己的興趣所在，這是一件非常好的事情，這種情況下你也不太可能會問出這樣的問題。

但是作為一個前端開發(fā)者，如果你想要通過 Rust 的學習來幫助你解決實際問題，或者追求更好的職業(yè)發(fā)展，我想在這里潑一盆冷水，Rust 并不是你必須要學習的技術(shù)。無論外界將 Rust 說得多么天花亂墜，無論大家對此談?wù)摰萌绾螣峄鸪?，你都沒有必要為此焦慮，因為在前端領(lǐng)域，Rust 僅僅只是那么一小部分人用來提升效率的手段，僅此而已，就跟你不會寫操作系統(tǒng)內(nèi)核也同樣不會受到任何影響一樣。

雖然沒有必要去學習 Rust，但我始終認為保持一個開放的心態(tài)和寬闊的視野是很重要的，像 Rspack、SWC、Oxc、Rspress 等等這些基于 Rust 的具有顛覆性的前端工具，大家不妨可以多多了解一下，如果能將這些工具應(yīng)用到實際的項目當中，那么你也能從中實際地受益。