React 的清算：業界最受喜愛的框架仍是正確選擇嗎？

超過十年來，React 一直是前端開發的重心。它引入的 Virtual DOM 與宣告式元件徹底改變了我們構建使用者介面的方式，讓業界遠離了 2010 年代初期的「jQuery 湯」時代。然而，越來越多的開發者、CTO 與工程師現在提出一個挑釁性的問題：真的有人喜歡 React 嗎？

近期在 Hacker News 與技術部落格上的討論顯示，我們正進入一個「後 React」時代——不一定是 React 消失，而是它作為預設選擇的地位正受到激烈質疑。批評已不僅僅是語法層面；更關乎效能、安全性，以及現代網路的根本架構。

反對單一文化的論點

最普遍的批評之一是 React 已變成「把所有事物都看成釘子的錘子」。業界已形成一種反射，討論新專案時常以「我們使用 React 吧，大家都熟悉 React」開頭，而不是先問「有哪些限制，哪個工具最適合？」

這種網路效應形成了自我循環。因為大多數開發者熟悉 React，公司便招聘 React 開發者，進而促使更多開發者學習 React。然而，這種「勞動套利」往往伴隨技術成本。批評者認為，這種單一文化扼殺前端創新，並導致對簡單問題的過度工程化解決方案。

除了社會動態之外，對 React 不斷演變的複雜性也有深層的挫敗感。從類別元件轉向 Hooks，現在又朝向 React Server Components (RSC) 發展，讓許多人感到框架彷彿在自訂規則的遊戲中。

許多開發者發現 React 的 hooks——尤其是 useEffect 與 useMemo——直覺上不易理解且難以精通。正如一位評論者所說，hooks「正確使用已相當棘手，若要在效能上使用更是難上加難」，常導致不必要的重新渲染與「 churn」現象，降低使用者體驗。

React 預設的 hydration 模式常被指為效能瓶頸。先在伺服器渲染 HTML，然後在客戶端以相同的 JavaScript「hydrate」它的過程，被部分人視為冗餘且浪費。這種「JS 重」的做法被認為與長期效能目標不相容，尤其對於使用低階硬體或慢速連線的使用者而言。

近期的安全漏洞，包括 React Server Components 中的關鍵遠端程式碼執行 (RCE) 漏洞 (CVE-2025-55182)，加劇了擔憂。一些開發者不僅對錯誤感到沮喪，也對 Vercel 與 React 團隊的治理與溝通表示不滿，形容部分回應「魯莽且不尊重社群」。

隨著挫敗感加劇，開發者正遷移至各種替代方案，每種方案解決 React 的不同問題：

Svelte 與 Solid.js： 這些框架因將工作從瀏覽器移至編譯階段、免除 Virtual DOM 的需求，從而產生更快、更精簡的應用程式而受到讚譽。
Vue： 有些人認為 Vue 的模型——元件只執行一次並建立反應式樹——更直觀，且較不需要 React 那樣的手動最佳化。
HTMX 與 Liveview： 對「超媒體」系統的興趣重新抬頭，這類系統將邏輯推回伺服器，減少送至客戶端的 JavaScript 數量，並簡化狀態管理流程。
「HTML 為先」的做法： 越來越多的運動倡導回歸網路基礎——以基礎 HTML 為底，搭配漸進增強，以確保可存取性與效能。

儘管批評聲浪不斷，仍有許多開發者為 React 辯護。支持它的論點往往是務實的：

「React 是最糟的 JS 框架，除了我們試過的所有其他框架之外。」

對許多人而言，JSX 的優雅與「元件即函式」的思維模型的簡潔性超過了種種挫敗感。支持者認為，宣告式、元件化的方式是大規模管理真正複雜 UI 的唯一途徑，而手動操作 DOM 則是產生難以維護的「意麵程式碼」的根源。

此外，生態系統——如 TanStack Query 等函式庫以及大量社群驅動的元件——提供了替代方案尚未匹敵的工具層級。對這些開發者而言，企業代碼庫的「混亂」是工程文化不佳的結果，而非工具本身的缺陷。

關於 React 的辯論不再是框架「好」或「壞」的問題，而是它是否是大多數網站的正確工具。業界開始意識到「肥客戶端」的 JS 重前端時代可能已達到巔峰。

未來是回歸伺服器端渲染、轉向細粒度反應性，或是採用混合方式，教訓都很明顯：預設框架的時代即將結束。未來十年最成功的工程師，很可能是能夠超越炒作，選擇最符合專案特定限制的工具，而非履歷上最受歡迎的那個。