如果一个待办清单也要打包 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。
因此、以“更少即更多”为原则重新审视页面架构；与此同时，渐进增强与可访问性将自然受益；尽管如此，团队需要建立“按场景拆分栈”的共识与标准。
前端×AI 实战笔记：CSS 动效 / React Hooks / Vue / LLM / Python。案例为主，持续更新；
归纳：更快、更轻、更聪明
- 范式：服务器优先，客户端按需；
- 目标：首屏可用先行，交互延后补齐；
- 方法：HTML 为底，零打包/低打包为轴，Resumability / 流式 / Islands 为翼。
若认同这条路径，传播、讨论、实践皆能推动生态演进——带来更快的站点、更低的能耗、更高的覆盖。 于是，所谓“抛弃框架”，并非否定框架价值，而是拒绝为不相称的负载买单；与此同时，选对工具即是选对成本曲线；因此，少即是多，此刻正当其时。
