"React的失敗并非因?yàn)樗缓?，而是因?yàn)樗晒α恕?

這句來自硅谷某獨(dú)角獸公司CTO的話讓我印象深刻。當(dāng)時(shí)我們在帕洛阿爾托的技術(shù)領(lǐng)袖聚會上小酌——那種第二輪酒過后大家就會暢所欲言的場合。話題轉(zhuǎn)向前端架構(gòu)時(shí)，我注意到這些閉門談話中存在著一種公開討論中未見的趨勢。

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

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

蜜月期結(jié)束

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

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

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

他的公司并未完全放棄React，但已停止擴(kuò)展React的使用范圍，并開始用其他技術(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)過數(shù)十次對話，工程領(lǐng)導(dǎo)者質(zhì)疑React投資的幾個(gè)明確模式浮出水面：

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

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

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

具體問題包括：

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 框架變更稅

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

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

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

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

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

5. 依賴安全噩夢

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

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

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

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

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

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

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

1. 回歸Vanilla JS配合針對性庫

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

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

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

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

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

3. 島嶼架構(gòu)

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

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

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

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

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

5. 內(nèi)部UI庫

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

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

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

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

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

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

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

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

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

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

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

1. 警惕單一文化效應(yīng)：當(dāng)一項(xiàng)技術(shù)過于主導(dǎo)時(shí)，會讓人忽視其局限性。
2. 評估持有成本而不僅是能力：許多CTO提到最初低估了React投資的長期維護(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)者對話中學(xué)到的內(nèi)容，但很好奇你的經(jīng)歷。你在組織中看到類似模式嗎？React在某些用例中已達(dá)極限，還是仍能滿足需求？