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

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

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

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

蜜月期結束

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

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

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

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

"React生態系統做出的一系列決策并不適合大型應用，"他告訴我，"持續的變動、規模擴展時的性能挑戰、日益復雜的思維模型——它們為構建嚴肅應用的團隊創造了完美風暴。"

驅動轉變的五大模式

經過數十次對話，工程領導者質疑React投資的幾個明確模式浮出水面：

1. 性能天花板效應

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

"我們有一支優秀的React開發團隊，他們已經優化了所有能優化的地方，"某C輪SaaS生產力公司的CTO Lisa K.說，"我們實現了虛擬化、記憶化、代碼分割、服務端組件——所有技術。但我們仍然觸及React核心設計中的根本限制。"

具體問題包括：

• 數據密集型大看板的渲染性能
• 規模擴展時出現問題的內存使用模式
• 初始加載性能，尤其在移動設備上
• 性能調試日益復雜

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

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

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

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

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

• 組件生命周期和鉤子
• 復雜狀態管理策略
• 記憶化和重渲染優化
• 數據獲取模式
• 服務端組件與客戶端組件
• Suspense和錯誤邊界
• 構建工具和配置

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

3. 人才與入職危機

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

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

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

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

4. 框架變更稅

React生態系統經歷了多次重大概念轉變：

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

每次轉變都需要大量重構、重新培訓，通常還要完全重寫共享庫和模式。

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

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

5. 依賴安全噩夢

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

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

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

這種包膨脹還影響構建時間、開發者體驗和架構靈活性。

他們轉向了何處？

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

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

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

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

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

2. 編譯器優先框架

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

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

3. 島嶼架構

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

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

4. WebAssembly用于關鍵性能路徑

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

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

5. 內部UI庫

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

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

PR問題：為何轉變悄然發生

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

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

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

明確地說，React不會很快消失。正在發生的是更微妙的變化——React從"萬物的默認選擇"轉變為"更專業化工具箱中的一件工具"。

"我們仍將React用于管理看板和內部工具，"某可持續交通初創公司CTO James L.說，"但已停止在性能關鍵的用戶端應用中使用它。"

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

給工程領導者的啟示

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

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

你的經驗是什么？

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