"React的失敗并非因為它不好，而是因為它太成功了。"

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

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

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

蜜月期結(jié)束

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

但多重因素正促使技術領導者重新評估他們的選擇：

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

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

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

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

經(jīng)過數(shù)十次對話，工程領導者質(zhì)疑React投資的幾個明確模式浮出水面：

1. 性能天花板效應

多位CTO提到React應用存在"性能天花板"。

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

具體問題包括：

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

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

2. 日益嚴重的"元工作"問題

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

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

所需掌握的知識已大幅擴展：

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

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

3. 人才與入職危機

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

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

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

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

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等
• 客戶端渲染 → 服務端渲染 → 服務端組件

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

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

另一位領導者更直白地表示："我們被迫在不斷重建地基的同時，還要往建筑上加蓋更多樓層。"

5. 依賴安全噩夢

幾乎所有工程領導者提到的最后一個問題是依賴管理。

"我們審計的典型React應用有1500到2000個npm依賴。安全和維護負擔已變得難以承受，"某網(wǎng)絡安全公司工程主管Wei C.解釋。

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

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

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

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

以下是公司報告的投資方向：

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

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

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

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

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

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

3. 島嶼架構(gòu)

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

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

4. WebAssembly用于關鍵性能路徑

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

多位提到探索將WebAssembly用于應用的高性能部分，同時對標準CRUD界面使用更簡單方案。

5. 內(nèi)部UI庫

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

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

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

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

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

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

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

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

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

給工程領導者的啟示

這些對話中最有價值的洞見并非關于React本身，而是關于技術選擇如何演進：

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

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

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