"React的失敗并非因?yàn)樗缓茫且驗(yàn)樗晒α恕?

這句來(lái)自硅谷某獨(dú)角獸公司CTO的話(huà)讓我印象深刻。當(dāng)時(shí)我們?cè)谂谅灏柾械募夹g(shù)領(lǐng)袖聚會(huì)上小酌——那種第二輪酒過(guò)后大家就會(huì)暢所欲言的場(chǎng)合。話(huà)題轉(zhuǎn)向前端架構(gòu)時(shí)，我注意到這些閉門(mén)談話(huà)中存在著一種公開(kāi)討論中未見(jiàn)的趨勢(shì)。

雖然React仍然占據(jù)著招聘啟事、技術(shù)大會(huì)和Twitter辯論的主流，但在許多頂尖科技公司的幕后，一場(chǎng)靜默的轉(zhuǎn)變正在發(fā)生。CTO們和工程負(fù)責(zé)人正在質(zhì)疑他們對(duì)React的長(zhǎng)期承諾，并探索替代方案——通常不會(huì)公開(kāi)宣布。

過(guò)去六個(gè)月里，我與24家高增長(zhǎng)科技公司的技術(shù)負(fù)責(zé)人進(jìn)行了交流。我的發(fā)現(xiàn)令人驚訝，可能會(huì)改變你對(duì)技術(shù)棧選擇的看法。

蜜月期結(jié)束

React作為主流前端框架已有近十年歷史。它改變了我們構(gòu)建Web應(yīng)用的方式，普及了基于組件的架構(gòu)，并創(chuàng)造了龐大的庫(kù)、工具和模式生態(tài)系統(tǒng)。

但多重因素正促使技術(shù)領(lǐng)導(dǎo)者重新評(píng)估他們的選擇：

某年交易額超20億美元的金融科技獨(dú)角獸工程副總裁Sandeep M.解釋道："我們?cè)?017年全面采用React。到2021年時(shí)，我們擁有一個(gè)由200多名開(kāi)發(fā)人員維護(hù)的大型應(yīng)用。那時(shí)擴(kuò)展性問(wèn)題已經(jīng)無(wú)法忽視。"

他的公司并未完全放棄React，但已停止擴(kuò)展React的使用范圍，并開(kāi)始用其他技術(shù)構(gòu)建新項(xiàng)目。

"React生態(tài)系統(tǒng)做出的一系列決策并不適合大型應(yīng)用，"他告訴我，"持續(xù)的變動(dòng)、規(guī)模擴(kuò)展時(shí)的性能挑戰(zhàn)、日益復(fù)雜的思維模型——它們?yōu)闃?gòu)建嚴(yán)肅應(yīng)用的團(tuán)隊(duì)創(chuàng)造了完美風(fēng)暴。"

驅(qū)動(dòng)轉(zhuǎn)變的五大模式

經(jīng)過(guò)數(shù)十次對(duì)話(huà)，工程領(lǐng)導(dǎo)者質(zhì)疑React投資的幾個(gè)明確模式浮出水面：

1. 性能天花板效應(yīng)

多位CTO提到React應(yīng)用存在"性能天花板"。

"我們有一支優(yōu)秀的React開(kāi)發(fā)團(tuán)隊(duì)，他們已經(jīng)優(yōu)化了所有能優(yōu)化的地方，"某C輪SaaS生產(chǎn)力公司的CTO Lisa K.說(shuō)，"我們實(shí)現(xiàn)了虛擬化、記憶化、代碼分割、服務(wù)端組件——所有技術(shù)。但我們?nèi)匀挥|及React核心設(shè)計(jì)中的根本限制。"

具體問(wèn)題包括：

• 數(shù)據(jù)密集型大看板的渲染性能
• 規(guī)模擴(kuò)展時(shí)出現(xiàn)問(wèn)題的內(nèi)存使用模式
• 初始加載性能，尤其在移動(dòng)設(shè)備上
• 性能調(diào)試日益復(fù)雜

某大型電商平臺(tái)工程總監(jiān)分享了內(nèi)部數(shù)據(jù)："盡管投入了三倍的工程資源，我們的React前端在交互復(fù)雜度達(dá)到原生應(yīng)用60%時(shí)就會(huì)遇到性能瓶頸。"

2. 日益嚴(yán)重的"元工作"問(wèn)題

另一個(gè)普遍抱怨是被幾位領(lǐng)導(dǎo)者稱(chēng)為"元工作"的現(xiàn)象——開(kāi)發(fā)者花費(fèi)在React特定架構(gòu)模式而非實(shí)際業(yè)務(wù)邏輯上的時(shí)間越來(lái)越多。

"2016年時(shí)React感覺(jué)很輕量。你能快速上手，"數(shù)字健康初創(chuàng)公司CTO Omar J.說(shuō)，"現(xiàn)在要構(gòu)建生產(chǎn)級(jí)React應(yīng)用，我的開(kāi)發(fā)人員60-70%時(shí)間都花在React特定模式、配置和優(yōu)化技術(shù)上，而不是解決實(shí)際業(yè)務(wù)問(wèn)題。"

所需掌握的知識(shí)已大幅擴(kuò)展：

• 組件生命周期和鉤子
• 復(fù)雜狀態(tài)管理策略
• 記憶化和重渲染優(yōu)化
• 數(shù)據(jù)獲取模式
• 服務(wù)端組件與客戶(hù)端組件
• Suspense和錯(cuò)誤邊界
• 構(gòu)建工具和配置

"我們計(jì)算出React開(kāi)發(fā)人員只有約30%時(shí)間在編寫(xiě)直接實(shí)現(xiàn)功能的代碼。其余時(shí)間都花在React元層上，"一位工程副總裁告訴我。

3. 人才與入職危機(jī)

幾位CTO提到一個(gè)意外問(wèn)題：雖然React開(kāi)發(fā)者眾多，但真正理解深層模式的高技能人才越來(lái)越稀缺且昂貴。

"我們能找到上百個(gè)會(huì)寫(xiě)React組件的開(kāi)發(fā)者。但要找到深刻理解React思維模型并能架構(gòu)大型應(yīng)用的人？這個(gè)人才池小得驚人，"某開(kāi)發(fā)者工具公司CTO Emily R.說(shuō)。

日益增長(zhǎng)的復(fù)雜性也帶來(lái)了入職挑戰(zhàn)： "2018年時(shí)，新工程師約兩周就能熟悉我們的React代碼庫(kù)。到2022年，新員工需要2-3個(gè)月才能在同一個(gè)應(yīng)用中真正高效工作，"某B2B SaaS平臺(tái)工程副總裁分享道，"學(xué)習(xí)曲線(xiàn)呈指數(shù)級(jí)增長(zhǎng)。"

多家公司報(bào)告稱(chēng)，他們最有經(jīng)驗(yàn)的工程師對(duì)日益增長(zhǎng)的復(fù)雜性感到沮喪，轉(zhuǎn)投使用其他技術(shù)的崗位。

4. 框架變更稅

React生態(tài)系統(tǒng)經(jīng)歷了多次重大概念轉(zhuǎn)變：

• 類(lèi)組件 → 函數(shù)組件+鉤子
• Redux → Context API → Signals/Zustand/Jotai等
• Render props → 高階組件 → 自定義鉤子
• Create React App → Next.js → Remix → Vite等
• 客戶(hù)端渲染 → 服務(wù)端渲染 → 服務(wù)端組件

每次轉(zhuǎn)變都需要大量重構(gòu)、重新培訓(xùn)，通常還要完全重寫(xiě)共享庫(kù)和模式。

"自2020年以來(lái)，我們超過(guò)40%的前端工程預(yù)算都花在跟上React生態(tài)系統(tǒng)的演進(jìn)上，而不是構(gòu)建新功能，"某大型市場(chǎng)平臺(tái)CTO透露。

另一位領(lǐng)導(dǎo)者更直白地表示："我們被迫在不斷重建地基的同時(shí)，還要往建筑上加蓋更多樓層。"

5. 依賴(lài)安全噩夢(mèng)

幾乎所有工程領(lǐng)導(dǎo)者提到的最后一個(gè)問(wèn)題是依賴(lài)管理。

"我們審計(jì)的典型React應(yīng)用有1500到2000個(gè)npm依賴(lài)。安全和維護(hù)負(fù)擔(dān)已變得難以承受，"某網(wǎng)絡(luò)安全公司工程主管Wei C.解釋。

一位金融科技CTO分享："審計(jì)時(shí)我們發(fā)現(xiàn)主React應(yīng)用的依賴(lài)樹(shù)中有86個(gè)已知漏洞，修復(fù)它們會(huì)破壞40%的組件。這簡(jiǎn)直是維護(hù)噩夢(mèng)。"

這種包膨脹還影響構(gòu)建時(shí)間、開(kāi)發(fā)者體驗(yàn)和架構(gòu)靈活性。

他們轉(zhuǎn)向了何處？

這些對(duì)話(huà)最有趣的部分不僅是領(lǐng)導(dǎo)者為何遠(yuǎn)離React，還有他們轉(zhuǎn)向了什么方向。目前沒(méi)有單一替代方案成為明確繼任者，這也是這種轉(zhuǎn)變悄然發(fā)生而非形成統(tǒng)一運(yùn)動(dòng)的部分原因。

以下是公司報(bào)告的投資方向：

1. 回歸Vanilla JS配合針對(duì)性庫(kù)

令人驚訝的是，許多公司轉(zhuǎn)向更原生的方案： "我們從最高流量的用戶(hù)流程中移除了React，改用Vanilla JavaScript配合小型專(zhuān)用庫(kù)，"某流媒體服務(wù)CTO說(shuō)，"頁(yè)面加載時(shí)間減少了60%，轉(zhuǎn)化率提高了14%。"

多位提到Lit、Alpine.js和Petite-Vue作為僅在需要處添加響應(yīng)式的輕量替代方案。

2. 編譯器優(yōu)先框架

Svelte和Solid在新項(xiàng)目中頻繁被提及，它們的編譯方法解決了React的許多運(yùn)行時(shí)性能問(wèn)題。 "在React性能問(wèn)題困擾后，我們用Svelte重建了賬戶(hù)管理門(mén)戶(hù)。同一團(tuán)隊(duì)用一半時(shí)間完成了項(xiàng)目，性能顯著提升，"某云基礎(chǔ)設(shè)施公司工程副總裁分享。

多位提到這些框架的思維模型對(duì)新開(kāi)發(fā)者更簡(jiǎn)單，減少了入職時(shí)間。

3. 島嶼架構(gòu)

另一種模式是轉(zhuǎn)向"島嶼架構(gòu)"，交互組件被隔離在主要是靜態(tài)的頁(yè)面中。 "我們現(xiàn)在對(duì)大多數(shù)營(yíng)銷(xiāo)和內(nèi)容站點(diǎn)使用Astro。僅對(duì)20%前端的復(fù)雜交互組件使用React，"某內(nèi)容平臺(tái)CTO解釋。

這種方法將React限制在真正需要其能力的部分，降低了整體復(fù)雜性和性能影響。

4. WebAssembly用于關(guān)鍵性能路徑

一些公司做出更激進(jìn)的轉(zhuǎn)變： "對(duì)于數(shù)據(jù)可視化看板，我們轉(zhuǎn)向使用Rust和Yew框架的WebAssembly方案，"某數(shù)據(jù)分析初創(chuàng)公司CTO說(shuō)，"性能差異不是漸進(jìn)式的——而是變革性的。"

多位提到探索將WebAssembly用于應(yīng)用的高性能部分，同時(shí)對(duì)標(biāo)準(zhǔn)CRUD界面使用更簡(jiǎn)單方案。

5. 內(nèi)部UI庫(kù)

少數(shù)大型公司報(bào)告構(gòu)建自己的輕量替代方案： "我們創(chuàng)建了專(zhuān)門(mén)針對(duì)用例優(yōu)化的內(nèi)部UI框架。它大約是React體積的20%，對(duì)我們需要的特性有更好的性能表現(xiàn)，"某流媒體公司首席工程師分享。

SWC等編譯器工具的興起使這種方法比過(guò)去更可行。

PR問(wèn)題：為何轉(zhuǎn)變悄然發(fā)生

如果這么多公司正在遠(yuǎn)離React，為何我們鮮少聽(tīng)聞？幾個(gè)因素在起作用：

1. 漸進(jìn)的轉(zhuǎn)變性質(zhì)：多數(shù)公司不做全面重寫(xiě)，而是將新項(xiàng)目轉(zhuǎn)向不同技術(shù)，同時(shí)維護(hù)現(xiàn)有React代碼庫(kù)。
2. 招聘顧慮："當(dāng)市場(chǎng)上仍有這么多React開(kāi)發(fā)者時(shí)，我們不想公開(kāi)宣布正在遠(yuǎn)離React，"一位工程副總裁解釋。
3. 職業(yè)投資因素：許多開(kāi)發(fā)者和工程領(lǐng)導(dǎo)者投入多年積累React專(zhuān)業(yè)知識(shí)，形成了變革的制度性阻力。
4. Meta/Facebook效應(yīng)：React與Meta/Facebook的關(guān)聯(lián)仍在技術(shù)決策中具有重要分量。

React在"消亡"嗎？不，但其角色正在變化

明確地說(shuō)，React不會(huì)很快消失。正在發(fā)生的是更微妙的變化——React從"萬(wàn)物的默認(rèn)選擇"轉(zhuǎn)變?yōu)?更專(zhuān)業(yè)化工具箱中的一件工具"。

"我們?nèi)詫eact用于管理看板和內(nèi)部工具，"某可持續(xù)交通初創(chuàng)公司CTO James L.說(shuō)，"但已停止在性能關(guān)鍵的用戶(hù)端應(yīng)用中使用它。"

另一位工程領(lǐng)導(dǎo)者這樣總結(jié)："React解決了Web開(kāi)發(fā)特定時(shí)代的一系列重要問(wèn)題。我們正進(jìn)入面臨不同挑戰(zhàn)的新時(shí)代。"

給工程領(lǐng)導(dǎo)者的啟示

這些對(duì)話(huà)中最有價(jià)值的洞見(jiàn)并非關(guān)于React本身，而是關(guān)于技術(shù)選擇如何演進(jìn)：

1. 警惕單一文化效應(yīng)：當(dāng)一項(xiàng)技術(shù)過(guò)于主導(dǎo)時(shí)，會(huì)讓人忽視其局限性。
2. 評(píng)估持有成本而不僅是能力：許多CTO提到最初低估了React投資的長(zhǎng)期維護(hù)和復(fù)雜性成本。
3. 關(guān)注創(chuàng)新者而非大多數(shù)：做出這些轉(zhuǎn)變的公司常處于前沿——他們今天的挑戰(zhàn)可能就是你明天的難題。
4. 考慮業(yè)務(wù)影響而非技術(shù)純粹性：做出改變的公司是受性能、轉(zhuǎn)化率和工程速度等業(yè)務(wù)指標(biāo)驅(qū)動(dòng)，而不僅是技術(shù)偏好。

你的經(jīng)驗(yàn)是什么？

我分享了從硅谷工程領(lǐng)導(dǎo)者對(duì)話(huà)中學(xué)到的內(nèi)容，但很好奇你的經(jīng)歷。你在組織中看到類(lèi)似模式嗎？React在某些用例中已達(dá)極限，還是仍能滿(mǎn)足需求？