如果要捕捉这场前端风向的转折，与其回忆社区里的争论，不如看几件实打实的变动。去年，博客平台 Medium 把原来的单页应用架构换成了以静态 HTML 为基础、再辅以少量 JavaScript 的方案，页面加载速率一下提升了六成有余，『服务器』压力也随之减轻。几乎同一时间，Shopify 在商家后台实行“HTML 优先”的改造，借助 Qwik 做局部增强，结果是代码库瘦身、操作顺滑，面对每天几十万商家的复杂业务也没有掉链子。把这些放在一处你会发现转折并不在某个框架，而是在使用 JavaScript 的方式：从无所不包，变成“该出手时才出手”。古人言“过犹不及”，今天读来分外贴切。
拐点并不在框架，而在观念
先把摆在前面：JavaScript 没有被抛弃，而是从统治者退成了干将。几年前 Next.js 推出 React Server Components，核心思路就是把绝大多数渲染放回『服务器』，客户端只背负必要的交互代码。许多使用者报告，改造之后客户端 JS 体积几乎减半，页面卡顿情况减少，这说明问题不在 JS 本身，而在过度把一切交给浏览器。同一逻辑，也在 Medium 的改造里得到了验证——HTML 先行，JS 点到为止，结构先到位，体验自然稳。
回望当年“全 JS”的热浪
如果把时间拨回十年前，前端圈子里“JS 优先”的思路几乎是显学。React、Vue 如日中天，SPA 成为各类站点的默认答案。开发者把 HTML、CSS 一股脑儿交给 JS 管控，甚至用 JS 去生成标签、拼装样式。理论上这能提升开发效率，实践中却暴露了另一面：白屏、首屏迟缓、SEO 抓不到内容、构建配置如迷宫。
一个做官网的小团队曾执意要用主流框架，结果光是 webpack 配置和 Tree Shaking 就折腾了半天，接下来又撞上“水合”这道坎——页面先白着，等 JS 起身、数据灌入，内容才露面。面对用户“打开半天没东西”的抱怨，老板只问了一个问题：“为啥别人能搜到，咱搜不到？”那一刻，很多人意识到自己绕了远路。更麻烦的是，前端在这套体系下被迫成了“半个运维”：兼管构建流、依赖、打包体积，甚至为每一毫秒苦战。有人为了让列表页快 0.5 秒，团队连续加班一周研究组件懒加载，最后也只换来数据微抖一记。
先把地基打好：HTML 的回归
风向转身，往往不是靠宣言，而是靠手感。一个朋友早年用某框架搭了博客，用户每次打开都要先忍受约三秒的白屏，他后来改用 Astro，基本框架由静态 HTML 构成，只在需要交互的组件上挂 JS。结果像是换了台新电脑：页面瞬开，搜索引擎抓取更及时。Astro 的默认策略是不加载任何客户端 JS，除非你明确给某个组件点灯，这种“组件岛”的思路把成本压到了能感知的地方。有人用它搭了个人技术博客，实际打开速度比原来的 Vue 版本快了近两倍，SEO 收录也明显顺滑，这是用户层面能直接感知的改变。
与 Astro 同路的，还有 HTMX。它让很多交互直接以 HTML 属性表达，比如一个表单提交，加个 hx-post 就能把数据发给『服务器』，并把返回的 HTML 片段替换到指定位置。做电商的朋友用它改购物车🛒，代码量几乎砍半，之前偶发的“提交失败”也没再复现。准确地说，这不是魔法，而是浏览器原生能力的再利用：表单、本地导航、渐进增强，都在。
复杂不等于必须把一切交给 JS
“HTML 优先能撑住复杂项目吗？”这句质疑在行业里反复被提起。观察几例现实案例，答案比想象中更乐观。
- Enhance 依托 Web Components 组织代码，先写 HTML 组件，再按需上 JS。有团队用它做了客户管理系统，几百个模块跑起来照样轻快，维护时也少了全局状态互相牵连的痛苦。
- Qwik 的厉害之处在于它不做全页面水合，只有用户点到哪个组件、滚到哪个区域，才按需下载与激活对应脚本。某『社交平台』用它重构动态消息流，滚动顺滑、交互及时，而在 React 版本里时常出现“滑着滑着卡住”的尴尬。
- Shopify 的实践最有说服力：后台业务体量复杂、使用频率高，但在采用“HTML 优先 Qwik 局部增强”后，代码库更轻、操作更流畅，这在高并发下尤其珍贵。
- 甚至有消息称，包括谷歌在内的大公司也在试水类似路线。路径不同，指向一致：别让 JS 啃掉所有地盘。
把路修平：制度小科普
要理解“HTML 优先”为何起效，几个概念值得一提。
- CSR 与 SSR：过去主流做法是 CSR（客户端渲染），浏览器拿到一个空壳，再用 JS 拼页面。SSR（『服务器』渲染）把初始页面直接在『服务器』产出，首屏更快，SEO 友好，客户端仅负责必要的交互。RSC 则进一步把 React 组件划分为“『服务器』版”和“客户端版”，从设计层面约束了 JS 的边界。
- 水合开销：CSR 模式下，初次渲染后还要把事件监听、状态同步回绑到 DOM 上，整个水合过程体积和时间都不便宜，尤其在移动端。
- 渐进增强：先保证核心内容和功能在无 JS 时也可用，然后在可用的环境里加速、美化。这不是倒退，而是分层设计。
- SEO 抓取：静态可见的 HTML 是搜索引擎的“通行证”。把关键内容直接输出，远比等待 JS 执行后再出现可靠。
从工具回到手艺：开发者的再学习
当 JS 不再充当大管家，开发者需要重新捡起被忽略的基本功。
- 语义化标签不只是“好习惯”。使用 article、nav、section 等标记出结构，屏幕阅读器能识别，导航就有了秩序。有人帮人改页面时，原本想着用 div 一把梭，结果辅助工具读不出来，不得不重排结构。对无障碍用户而言，这不是细枝末节。
- HTTP 动词是真正的状态管理工具。登录表单提交给『服务器』，『服务器』以 Set-Cookie 建立会话，刷新页面状态不丢，不需要在前端费劲保存 token、处理刷新逻辑。有开发者用表单和 GET/POST 架起了一个简易后台，代码量比 Vue 方案少了三分之二，稳定性反而更高。
- CSS 的能力远未用尽。响应式布局靠媒体查询，组件自适应用容器查询，很多本来交给 JS 的活儿可以还给样式层。有人做产品展示页，只用容器查询就实现了不同宽度下的不同编排，一行 JS 未写，比插件更灵活，也更易维护。
横向对比：谁在承担“复杂度税”
把几种方案摆在一起会更清楚“复杂度税”究竟落在谁身上。
- 全 JS 的 SPA：构建链条长、依赖众多、首屏等待、SEO 先天不足。开发者要处理 webpack、Tree Shaking、水合，性能优化像无底洞。
- HTML 优先 局部 JS：首屏可见、抓取友好、交互有的放矢。复杂度转移到『服务器』模板、数据接口与少量组件 JS 上，团队分工更清晰。
- RSC 与“组件岛”：在组件维度切割 SSR/CSR 边界，避免“一刀切”。用的人反馈客户端包减半，卡顿减少，正是因为不再让浏览器承担不该承担的部分。
故事背后的心理与团队现实
技术潮流的转弯，不只因为跑分和指标，也与团队体验有关。一个典型的抱怨是：我们是在解决用户问题，还是在给自己找事？当你为了优化 0.5 秒的加载时间连续加班，或是为升级依赖修三天冲突，难免会怀疑方向是否正确。而当 Astro 之类的方案让你“开箱即用”地得到可见的提升，当 HTMX 的一个属性就能完成交互，技术这件事又恢复了“顺手”的感觉。“大道至简”，往往更接近用户与开发者的共同利益。
再回到那些案例，给这段“技术史”画出一条线
- Medium 去年拥抱静态化 轻 JS，速度提升六成有余、『服务器』压力变小，这是对性能的直击。
- Shopify 用 Qwik 为后台做局部增强，代码库瘦了、操作更顺，用事实回应了“复杂系统也能 HTML 优先”的质疑。
- Astro 以默认零 JS 的策略带来直观的首屏体验，开发者的个人博客因此比 Vue 版快近一倍，且 SEO 成果可见。
- HTMX 让表单交互回到 HTML 自身，电商购物车🛒的代码量几近腰斩，可靠性提高。
- Next.js 推 RSC，把客户端包瘦身近半，说明“把 JS 用在刀刃上”是可行的工程路线。
- Enhance 和 Qwik 分别从 Web Components 与“按需激活”两端切入，让“复杂 ≠ 笨重”成为现实。
- 谷歌、Shopify等大公司在试水，显示这不是孤例，而是共识的形成。
从结局回推因果，不难看清脉络：JS 并非不行，它只是被我们使用过度了。当我们让 HTML 打基础、CSS 定形、JS 点睛，浏览器的原生能力被整合回来，用户体验也自然地稳了下来。
面向未来的分工与期待
框架不会消失，它们会进化成帮助实现“HTML 优先”的工具：在『服务器』端更好地渲染，在客户端更聪明地加载。开发工作也会更像老匠人“分料下刀”：先立结构，再铺样式，最后补交互。比起炫技，大家更愿意去比谁的站点起步更快、交互更顺、无障碍更完善、搜索更友好。
也许最动人的地方在于，这像是一段往返：十年的折腾之后，前端重新回到了“以用户为本”的路径上。不是倒退，而是回归本质；不是弃用 JS，而是学会“不过度”。当我们再次相信 HTML 的力量、尊重浏览器的能力、谨慎地使用 JS，技术史上的这次转身，才算真正落地。
