背景

這篇文章源自一位在 Automattic 負責網頁效能的工程師，他根據多年維護大型專案的經驗，指出過度依賴 JavaScript（尤其是 React 等框架）的開發模式，與長期的效能目標背道而馳。作者認為，這種「JS 重型」的開發方式雖然被包裝成提升開發效率的現代標準，但實際上卻常導致 bundle 體積失控、渲染效能下降，並主張應回歸以伺服器為中心的開發模式。

社群觀點

Hacker News 的討論呈現出明顯的世代交替感與對現狀的疲勞。許多資深開發者深有同感，感嘆網頁開發似乎陷入了「每隔幾年就重新發明輪子」的循環。支持者指出，二十年前的網頁在硬體效能極低的情況下，反應速度反而比現在動輒數 MB 的單頁式應用程式（SPA）更快。他們認為伺服器渲染（SSR）能提供更直覺的效能優勢，因為瀏覽器只需處理已經生成的 HTML，而不必在客戶端執行繁重的解析與運算。

然而，反對意見則認為將問題全歸咎於 JavaScript 過於片面。部分留言者指出，作者的經驗大多侷限於 React 與 Redux，這兩者在現代框架中已顯得相對臃腫。新興框架如 Svelte、Solid 或 Vue 在 bundle 體積與渲染速度上已大幅逼近原生 JS 的水準。他們爭辯道，將邏輯移回伺服器並非萬靈丹，因為這意味著每一次互動都需要經歷網路往返的延遲，對於需要高度互動性的編輯器類應用（如 Figma），客戶端渲染反而是唯一能保證低延遲的方案。

討論中一個核心的爭論點在於「DOM 是否為效能瓶頸」。有觀點認為 DOM 本質上是為文件設計的，而非複雜的應用程式介面，因此像 Figma 這樣繞過 DOM、改用 WebAssembly 與 Canvas 的做法才是真正的效能解方。但也有開發者反駁，DOM 存取速度在現代瀏覽器中已經極快，真正的效能殺手通常是框架層疊加的複雜邏輯，或是開發者在引入 npm 套件時缺乏節制，導致相依性過度膨脹。

此外，社群對 GitHub 近期的效能退化有著強烈共鳴。不少人批評 GitHub 在被微軟收購並引入更多 React 組件後，操作感變得沉重且緩慢。這引發了關於「開發者體驗（DevEx）」與「使用者體驗（UX）」衝突的討論：企業往往為了招募方便或開發便利選擇主流框架，卻忽視了低階設備使用者在解析大量 JS 時的痛苦。最終，社群達成了一種微妙的共識：工具本身沒有對錯，問題在於業界盲目追求框架的「現代化」，而忽略了根據應用場景選擇最合適技術的工程直覺。

延伸閱讀

在討論串中，開發者們推薦了幾個值得關注的替代方案與資源，包括強調極簡與高效能的 Datastar 框架，以及能讓網頁組件在無 JS 環境下仍具備基本功能的漸進式增強技術。此外，infrequently.org 網站上的文章被多次提及，被認為是深入理解網頁效能底層邏輯的必讀資源。針對狀態管理，留言者也推薦了比 Redux 更直覺的 MobX，以及專為現代網頁設計的 Qwik 框架。