為什么越來越多人“拋棄”JavaScript 框架
如果一個待辦清單也要打包 400 KB 的 JavaScript 才能渲染——此刻或許值得停下來想一想。
過去一年，JavaScript 社區里悄然興起了一場“靜悄悄的反叛”。不喧嘩、不張揚，卻持續擴散——而且高效致命。 一個直截了當的問題被頻繁提出：能否在不下發龐大前端包的前提下，構建現代 Web 應用？
答案指向同一方向：零打包（zero-bundle） 思路。
“零打包”并非筆誤，而是一種范式
并不是笑話，而是思維重置：與其把瀏覽器當成“框架的豪華運行時”，不如讓服務器重新坐回駕駛位。 一批工具正沖鋒在前（按字母序）：
- HTMX：僅用 HTML 屬性“點綴”動態行為；無需構建工具、無需 hydration。
- Qwik：提出 Resumability（可續執行）：JavaScript 可以從服務器停下處繼續執行，幾乎沒有 hydration 懲罰。
- Marko（eBay 團隊）：全量流式 HTML + 交互小島（islands），只在必要時按需激活。
這些方案把重點落在首屏啟動快、JS 負載輕、真實場景性能——而非唯 Lighthouse 分數論。 因此、在冷啟動敏感、網絡受限、設備性能參差的現實里，它們更像“回歸常識”的技術。
現有主流框架出了什么問題？
嚴格說，問題不在框架本身——直到低端設備上的 TTI（可交互時間） 被認真度量。React / Vue / Svelte 等在包下載、解析、hydration 完成之后表現出色； 然而，在此之前？用戶面對的是一張“凍結”的頁面。 于是，一個“模型翻轉”的思路浮現：服務器優先渲染（server-first）。
- 服務器直接下發可用的 HTML；
- 交互稍后到達，且只在需要之處加載。
這里并非“去 JS 化”。核心是：不要為了一份本可由 HTML 承擔的靜態結構，提前發送 90% 無關的 JS——更別在客戶端再把相同的 HTML“重渲染一次”。 因此、就加載路徑、就可靠性、就功耗而言，減法往往勝過盲目的加法；與此同時，復雜交互仍可按需注入；盡管如此，初次可用的速度被顯著改善。
為什么偏偏是現在
多股趨勢在 2025 年疊加，使“零 JS 首屏/零打包”成為可行選項：
- 瀏覽器 DOM 更新已非常快——多數情況下快過通用前端框架抽象層。
- 移動端與低帶寬用戶仍占比不小——性能“木桶效應”更明顯。
- 邊緣節點與無服務器基礎設施普及——動態 HTML 的延遲與吞吐兼得。
- 工程疲勞積累——七層嵌套的構建配置令人厭倦；維護成本被放大。
- 用戶只在乎“快”——至于用沒用某框架，用戶并不關心。
因此、以用戶感知為錨點的技術決策被重新重視；同時，以平臺能力為基礎的“回歸服務器”路徑變得順理成章；盡管如此，客戶端富交互仍有其不可替代的價值。
“React 已死”嗎？
結論是否定的，但“唯一答案”的時代已結束。 React 依舊擅長重交互界面：數據密集的儀表盤、設計類工具、媒體應用等。 然而，對于內容優先的體驗（電商列表、博客、表單、商品詳情等），更少的 JS已經成為競爭優勢。 因此、技術選型進入“按需擇器”階段： 不再因為“同行都在做 SPA”就盲目跟隨；與此同時，框架生態與團隊熟練度仍要計入成本；盡管如此，性能與可達性在許多業務里正在回到核心。
面向 2025 年的前端工程建議
- 認識 HTMX：范式簡單、上手清爽。
- 探索 Qwik：前沿理念有望反哺未來框架設計。
- 嘗試 Marko：在復雜站點里，對“何時加載、加載多少”有精細掌控。
- 重新評估 React 的必要性：并非處處皆需 SPA。
因此、以“更少即更多”為原則重新審視頁面架構；與此同時，漸進增強與可訪問性將自然受益；盡管如此，團隊需要建立“按場景拆分棧”的共識與標準。
歸納：更快、更輕、更聰明
- 范式：服務器優先，客戶端按需；
- 目標：首屏可用先行，交互延后補齊；
- 方法：HTML 為底，零打包/低打包為軸，Resumability / 流式 / Islands 為翼。
若認同這條路徑，傳播、討論、實踐皆能推動生態演進——帶來更快的站點、更低的能耗、更高的覆蓋。 于是，所謂“拋棄框架”，并非否定框架價值，而是拒絕為不相稱的負載買單；與此同時，選對工具即是選對成本曲線；因此，少即是多，此刻正當其時。
