作者 | Loren Stewart

譯者 | 劉雅夢

策劃 | Tina

React 不再因技術(shù)優(yōu)勢而獲勝。今天，它已經(jīng)是默認(rèn)的選擇。這種默認(rèn)選擇現(xiàn)在正在減緩前端生態(tài)系統(tǒng)的創(chuàng)新。

當(dāng)團(tuán)隊(duì)需要一個(gè)新的前端時(shí)，對(duì)話通常很少從“有哪些限制，哪個(gè)工具最適合它們？”開始。而是從“我們使用 React；每個(gè)人都了解 React。”開始。這種條件反射創(chuàng)造了一個(gè)自我持續(xù)的循環(huán)，在這個(gè)循環(huán)中，決定架構(gòu)的是網(wǎng)絡(luò)效應(yīng)，而不是技術(shù)契合度。

與此同時(shí)，真正創(chuàng)新的框架難以獲得采用。Svelte 編譯掉了框架開銷。Solid 提供了細(xì)粒度的反應(yīng)性，無需虛擬 DOM 稅。Qwik 通過可恢復(fù)性實(shí)現(xiàn)了即時(shí)啟動(dòng)。這些方法可以在常見場景中優(yōu)于 React 的模型，但由于 React 是默認(rèn)選擇，它們很少得到公平的評(píng)估。

React 在許多方面都做得很好。問題不在于 React 本身，而在于默認(rèn)選擇 React 的心態(tài)。

創(chuàng)新天花板

React 的技術(shù)基礎(chǔ)解釋了當(dāng)今的一些摩擦。虛擬 DOM 是 2013 年問題的聰明解決方案，但正如 Rich Harris 在“虛擬 DOM 是純粹的開銷”中概述的那樣，它引入了現(xiàn)代編譯器通?？梢员苊獾墓ぷ?。

鉤子解決了類組件的痛點(diǎn)，但引入了新類型的復(fù)雜性：依賴數(shù)組、陳舊的閉包和誤用的 Effect。即使是 React 自己的文檔也強(qiáng)調(diào)克制：“你可能不需要一個(gè) Effect”。服務(wù)器組件提高了首字節(jié)時(shí)間，但增加了架構(gòu)復(fù)雜性和新的故障模式。

React 編譯器是一個(gè)智能的解決方案，可以自動(dòng)執(zhí)行諸如 useMemo / useCallback 之類的模式。它的存在也是一個(gè)信號(hào)：我們正在圍繞模型中固有的限制進(jìn)行優(yōu)化。

將此與其他方法進(jìn)行對(duì)比：Svelte 5 的 Runes 在編譯時(shí)簡化了反應(yīng)性；Solid 的細(xì)粒度反應(yīng)性精確更新了變化的內(nèi)容；Qwik 的可恢復(fù)性消除了傳統(tǒng)的水合。這些不是對(duì) React 模型的增量調(diào)整——它們是具有不同天花板的不同模型。

沒有采用的創(chuàng)新不會(huì)改變結(jié)果。當(dāng)選擇是出于條件反射時(shí)，采用就無法發(fā)生。

我們都背負(fù)著技術(shù)債

默認(rèn)選擇 React 通常會(huì)帶來我們不再質(zhì)疑的運(yùn)行時(shí)和調(diào)和成本。即使它足夠快，上限也低于編譯時(shí)或細(xì)粒度模型。開發(fā)者的時(shí)間花在管理重新渲染、effect 依賴項(xiàng)和水合邊界上，而不是交付價(jià)值。從性能研究中得到的更廣泛的教訓(xùn)是一致的：JavaScript 在關(guān)鍵路徑上是昂貴的（JavaScript 的成本）。

我們把思維模型集中在“React 模式”上，而不是 web 基礎(chǔ)上，這降低了技能的可移植性，更有可能導(dǎo)致架構(gòu)惰性。

損失的不僅僅是性能，還有機(jī)會(huì)成本，因?yàn)楦线m的替代方案從未得到評(píng)估。例如，像 JS 框架基準(zhǔn)測試這樣的基準(zhǔn)測試顯示，與 React 相比，Solid 等替代方案在反應(yīng)性重的場景中實(shí)現(xiàn)了高達(dá) 2-3 倍的更快更新速度。

被壓抑著的框架

Svelte：編譯器革命

Svelte 將工作轉(zhuǎn)移到編譯時(shí)：沒有虛擬 DOM，最小的運(yùn)行時(shí)。組件成為目標(biāo) DOM 操作。心智模型與網(wǎng)絡(luò)基本原理對(duì)齊。

但是“沒有足夠的工作”人為地降低了 Svelte 的采用率，管它在大多數(shù)用例中具有技術(shù)優(yōu)勢。像衛(wèi)報(bào)采用 Svelte 作為他們的前端這樣的現(xiàn)實(shí)世界例子，展示了性能和開發(fā)者生產(chǎn)力的可衡量收益，據(jù)報(bào)道，包大小減少了，加載時(shí)間也加快了。例如，正如 Wired 關(guān)于 Svelte 的文章中所詳細(xì)說明的，開發(fā)者 Shawn Wang（X/Twitter 上的 @swyx）通過利用其編譯時(shí)優(yōu)化，將他的網(wǎng)站大小從 React 的 187KB 減少到僅 9KB 的 Svelte，這將框架開銷從運(yùn)行時(shí)上轉(zhuǎn)移開。這導(dǎo)致更快、更高效的應(yīng)用程序，特別是在慢速連接上。

Solid：反應(yīng)性原語方法

Solid 提供了熟悉 JSX 的細(xì)粒度反應(yīng)性。更新通過信號(hào)直接流向受影響的 DOM 節(jié)點(diǎn)，繞過調(diào)和瓶頸。強(qiáng)大的性能特征，有限的心智份額。正如 Solid 的比較指南中概述的，這種方法比 React 的虛擬 DOM 實(shí)現(xiàn)了更有效的更新，精確的反應(yīng)性最小化了不必要的工作，并通過更簡單的狀態(tài)管理提高了開發(fā)者體驗(yàn)。

雖然與更成熟的框架相比，突出的案例研究較少，但這主要是由于 Solid 的采用率較低。然而，來自早期采用者的軼事報(bào)告表明，在更新效率和代碼簡單性方面也有類似的變革性收益，隨著更多團(tuán)隊(duì)的實(shí)驗(yàn)，這些收益將被擴(kuò)展和共享。

Qwik：可恢復(fù)性創(chuàng)新

Qwik 使用可恢復(fù)性代替水合，通過僅加載當(dāng)前交互所需的內(nèi)容實(shí)現(xiàn)即時(shí)啟動(dòng)。這對(duì)于大型網(wǎng)站、長時(shí)間會(huì)話或慢速網(wǎng)絡(luò)非常理想。根據(jù) Qwik 的“Think Qwik”指南，這是通過漸進(jìn)式加載和序列化狀態(tài)和代碼來實(shí)現(xiàn)的。因此，應(yīng)用程序可以立即恢復(fù)執(zhí)行，而無需繁重的客戶端引導(dǎo)，與傳統(tǒng)框架相比，這帶來了更好的可擴(kuò)展性和更短的初始加載時(shí)間。

Qwik 的成功案例可能不那么明顯，僅僅是因?yàn)檩^少的團(tuán)隊(duì)打破默認(rèn)設(shè)置嘗試它。但那些嘗試過的人報(bào)告了啟動(dòng)時(shí)間和資源效率的顯著改進(jìn)，這表明如果采用率增長，將有大量未開發(fā)的潛力。

所有三種方法被低估的原因不是因?yàn)樗鼈內(nèi)狈?yōu)點(diǎn)，而是因?yàn)槟J(rèn)選擇阻礙了嘗試。

此外，React 的 API 表面積明顯比其替代品更大、更復(fù)雜，涵蓋了鉤子、上下文、約簡器和記憶模式等概念，需要仔細(xì)管理以避免陷阱。這種廣泛的 API 為開發(fā)者帶來了更高的認(rèn)知負(fù)荷，常常導(dǎo)致由于誤解依賴關(guān)系或過度工程化而產(chǎn)生的缺陷。例如，在 Cloudflare 2025 年 9 月 12 日的停機(jī)事件中，一個(gè) useEffect 鉤子和一個(gè)有問題的依賴數(shù)組觸發(fā)了重復(fù)的 API 調(diào)用，壓垮了他們的租戶服務(wù)，導(dǎo)致了廣泛的故障。相比之下，像 Svelte、Solid 和 Qwik 這樣的框架具有更小、更專注的 API，強(qiáng)調(diào)簡單性和網(wǎng)絡(luò)基礎(chǔ)，減少了心理負(fù)擔(dān)，使它們更容易掌握和維護(hù)。

網(wǎng)絡(luò)效應(yīng)的監(jiān)獄

React 的主導(dǎo)地位創(chuàng)造了自我強(qiáng)化的障礙。招聘廣告要求“React 開發(fā)人員”，而不是“前端工程師”，這限制了技能的多樣性。組件庫和團(tuán)隊(duì)肌肉記憶創(chuàng)造了制度慣性。

風(fēng)險(xiǎn)厭惡的領(lǐng)導(dǎo)者選擇“安全”的選項(xiàng)。學(xué)校教授工作要求的內(nèi)容。這個(gè)循環(huán)不受技術(shù)價(jià)值的影響而繼續(xù)。

這不是良性競爭；這是默認(rèn)的生態(tài)系統(tǒng)捕獲。

打破網(wǎng)絡(luò)效應(yīng)

逃離需要在多個(gè)層面上采取深思熟慮的行動(dòng)。技術(shù)領(lǐng)導(dǎo)者應(yīng)該根據(jù)約束和優(yōu)點(diǎn)來進(jìn)行選擇，而不是基于勢頭。公司可以分配一個(gè)小的創(chuàng)新預(yù)算來嘗試替代品。開發(fā)人員可以超越單一的思維模式進(jìn)行技能提升。

教育者可以在教授特定工具的同時(shí)教授與框架無關(guān)的概念。開源貢獻(xiàn)者可以幫助替代生態(tài)系統(tǒng)成熟。

改變不會(huì)自動(dòng)發(fā)生。它需要有意識(shí)的選擇。

框架評(píng)估清單

在開始一個(gè)新項(xiàng)目時(shí)，使用這個(gè)簡單的清單來做出有意識(shí)的選擇：

• 評(píng)估性能需求：評(píng)估啟動(dòng)時(shí)間、更新效率和捆綁包大小等指標(biāo)。如果速度至關(guān)重要，那么優(yōu)先選擇具有編譯時(shí)優(yōu)化的框架。

• 團(tuán)隊(duì)技能和學(xué)習(xí)曲線：考慮現(xiàn)有的專業(yè)知識(shí)，但要考慮到遷移路徑；許多替代品提供溫和的坡道（例如，Solid 與 React 的 JSX 兼容性）。

• 擴(kuò)展和擁有成本：計(jì)算長期成本，包括維護(hù)、依賴管理和技術(shù)債。替代品通?？梢詼p少運(yùn)行時(shí)開銷，降低托管成本并提高可擴(kuò)展性。

• 生態(tài)系統(tǒng)適應(yīng)性：在成熟度和創(chuàng)新之間取得平衡；在非關(guān)鍵領(lǐng)域進(jìn)行試點(diǎn)，以測試遷移的可行性和投資回報(bào)率。

標(biāo)準(zhǔn)反駁論點(diǎn)

“但是生態(tài)系統(tǒng)成熟度！”成熟度是有價(jià)值的，也可能使慣性根深蒂固。年齡不等于適應(yīng)當(dāng)今的約束。

此外，成熟的生態(tài)系統(tǒng)通常意味著嚴(yán)重依賴第三方包，這可能會(huì)引入維護(hù)負(fù)擔(dān)，如保持依賴關(guān)系最新、處理安全漏洞、以及使用未使用到的代碼使包膨脹。雖然在某些情況下是必要的，但這種靈活性可能導(dǎo)致過度依賴；從長遠(yuǎn)來看，針對(duì)特定需求量身定制的解決方案通常更精簡、更易于維護(hù)。替代框架中的較小生態(tài)系統(tǒng)鼓勵(lì)從基礎(chǔ)構(gòu)建，培養(yǎng)更深入的理解和較少的技術(shù)債。此外，隨著 AI 編碼助手現(xiàn)在能夠按需生成精確的定制功能，創(chuàng)建定制實(shí)用程序的障礙已經(jīng)大大降低了。這使得避開像 lodash 這樣的通用庫或像 Moment 或 date-fns 這樣的日期庫來完全支持輕量級(jí)的、特定于應(yīng)用程序的實(shí)現(xiàn)成為可能。

“但是招聘！”招聘跟隨需求。你可以通過在非關(guān)鍵路徑上試點(diǎn)替代品，然后在招聘基礎(chǔ)加上在職培訓(xùn)來降低風(fēng)險(xiǎn)。

“但是組件庫！”框架無關(guān)的設(shè)計(jì)系統(tǒng)和 Web 組件減少了鎖定，同時(shí)能保持速度。

“但是穩(wěn)定性！”React 從類到鉤子再到服務(wù)器組件的演變表明了不斷的混亂，而不是穩(wěn)定性。替代框架通常能提供更一致的 API。

“但是經(jīng)過規(guī)模證明！”jQuery 也經(jīng)過了規(guī)模證明。過去的成功并不能保證未來的相關(guān)性。

更廣泛生態(tài)系統(tǒng)的危害

當(dāng)一個(gè)框架的約束成為事實(shí)上的限制時(shí)，單一文化會(huì)減緩 Web 的演變。人才花時(shí)間解決特定框架的問題，而不是推動(dòng)平臺(tái)向前發(fā)展。不管技術(shù)優(yōu)勢如何，投資總是追隨在位者。

課程優(yōu)化了直接就業(yè)能力，而不是基礎(chǔ)知識(shí)，創(chuàng)造了特定框架而非可轉(zhuǎn)移的技能。平臺(tái)改進(jìn)會(huì)被推遲，因?yàn)椤癛eact 可以處理”成為了默認(rèn)答案。

當(dāng)多樣性消失時(shí)，整個(gè)生態(tài)系統(tǒng)都會(huì)受到影響。

我們本可以成長的花園

健康的生態(tài)系統(tǒng)需要多樣性，而不是單一文化。當(dāng)不同的方法競爭和交叉授粉時(shí)，創(chuàng)新就會(huì)出現(xiàn)。開發(fā)者通過學(xué)習(xí)多種思維模式而成長。當(dāng)幾個(gè)框架突破不同的界限時(shí)，平臺(tái)就會(huì)得到了改善。

把所有賭注都押在一個(gè)模型上會(huì)造成單點(diǎn)故障。如果它遇到硬性限制會(huì)怎樣？我們不探索替代方案會(huì)錯(cuò)過什么機(jī)會(huì)？

是時(shí)候根據(jù)限制和價(jià)值而非勢頭來選擇框架了。你的下一個(gè)項(xiàng)目值得比默認(rèn)的 React 更好。生態(tài)系統(tǒng)值得多樣性才能提供的創(chuàng)新。

不要再默認(rèn)種植相同的種子。通過多樣化框架探索，我們本可以培育的花園將比我們逐漸陷入的單一文化更具韌性和創(chuàng)新性。

選擇權(quán)在我們手中。

https://www.lorenstew.art/blog/react-won-by-default

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。