夜雨聆风时尚是一个轮回，前端也是。
只是这一轮回来的，不会是原封不动的旧 Web，而是叠加了 AI、边缘计算、现代浏览器 API 和自动化工具之后的新Web。
我以前不大相信“时尚是一个轮回”这句话，觉得这是卖衣服的人想出来安慰库存的。后来发现不是这样。宽裤腿会回来，复古球鞋会回来，老花纹也会回来。只要隔得足够久，很多曾经被嫌弃的东西，都会换一副面孔重新登场。
现在看前端，也有点这个意思。
很多年前，我们做网站，主要是在写 HTML、CSS 和一点 JavaScript。页面就是页面，链接就是链接，表单就是表单。一个网页能打开，能阅读，能提交，能被搜索引擎抓到，基本就算有了体面。后来前端长大了，开始写应用，写组件，写状态，写路由，写构建配置，写服务端渲染，写全栈框架。前端长得越来越像一座城市，当然也越来越像一座迷宫。
这不是坏事。复杂应用需要复杂技术。问题在于，我们后来有时忘了：不是所有网页都需要变成一座城市。有些页面本来只需要是一条清楚的路、一间明亮的屋子、一个能被人和机器都看懂的说明牌。
AI 出现以后，这件事变得更有意思。因为 AI 正在把“写代码”这件事的门槛往下压。它能生成页面，能改模板，能接接口，能修报错，能写配置。于是一个老问题又冒出来了：如果写代码不再是最稀缺的能力，那么前端到底还稀缺什么？
我以为答案会重新落到四个词上：语义化、高性能、渐进增强、机器友好。
前端曾经离 HTML 很近，后来离它越来越远
有件事说起来有点滑稽：前端工程师这个职业，名字里带着“前端”，但很多时候，前端工程师已经不怎么直接面对真正的 Web 了。
我们面对的是组件、props、hooks、store、路由、插槽、构建产物、打包体积、hydration、server component，以及各种听起来很有道理的抽象。它们当然有用，但也带来了一个副作用：HTML 在很多项目里变成了框架的输出结果，而不是工程师思考的起点。
一个页面到底应该是 article，还是 section？这里是不是应该有一个真正的 nav？这个提交动作是不是应该先是一个 form，再谈脚本增强？这些问题原本很朴素，现在反而像冷门知识。
更严重一点说，在一些纯客户端应用里，开发者可以很长时间不关心 SEO 是否友好，不关心没有 JavaScript 时页面还剩下什么，不关心读屏器读到的是一篇文章还是一堆按钮，也不关心搜索引擎和 AI Agent 看到的到底是什么。只要组件能跑、接口能调、交互能点，事情似乎就完成了。
这当然不能全怪框架。框架只是工具，工具没有原罪。但工具一旦太顺手，人就容易忘记工具底下还有一层东西。就像一个人天天坐电梯，久而久之会忘了楼梯在哪里。等到停电时，才想起楼梯不是装饰品。
AI 时代的“停电”也许不是停电，而是另一种考验：机器要理解你的页面。
搜索引擎要理解，浏览器要理解，辅助技术要理解，自动化工具要理解，未来替用户执行任务的 AI Agent 也要理解。它们面对的不是你脑子里的组件设计，也不是项目会上讲的架构图，而是最终输出的 Web 结构。
如果一个页面有清楚的标题、段落、导航、文章、表单、时间和列表，它就比较容易被理解。article 像文章，nav 像导航，main 像主体，form 像表单，button 像按钮，这些东西看上去不新潮，但它们胜在诚实。
诚实的结构，对人有好处，对机器也有好处。
所谓回到 Web，不是回到刀耕火种
一听说“回到 Web 本身”，有些人会紧张，好像马上要把现代前端都扔掉，大家重新用记事本写页面。这种理解未免太艰苦朴素了。
我说的回到 Web，不是回到刀耕火种，而是回到优先级。
能用语义化 HTML 表达的，先用 HTML 表达；能用 CSS 解决的，不急着写 JavaScript；能由浏览器原生处理的，不一定要造一个组件；能在服务端、构建阶段、边缘节点完成的，不必都搬到客户端运行。
这不是反对框架，而是反对不必要的框架化。复杂应用当然还需要强框架。在线编辑器、设计工具、协同文档、复杂后台、数据平台，这些东西不可能靠几行 HTML 就解决。但大量官网、文档站、博客、落地页、营销页、产品介绍页、知识库和轻交互页面，真正需要的也许不是一套庞大的客户端应用，而是更快的首屏、更少的 JavaScript、更稳定的结构和更容易被 AI 修改的内容。
过去我们常常用解决复杂应用的办法，去解决简单页面的问题。就好比为了煮一碗面，先修一座厨房综合体。这个厨房当然先进，问题是面早就坨了。
AI 会让这个问题更明显。因为页面会被更快地生成、复制、改写和组合。如果每个页面默认都带着很重的运行时、很复杂的依赖和很绕的抽象，最后不是 AI 提效，而是 AI 帮我们更快地制造复杂性。
所以高性能不该是最后的优化项目，而应该是默认值。少依赖，少运行时，少阻塞，少无效 JavaScript。这听起来不像什么新技术，但很多时候，少做一点就是最有效的技术决策。
渐进增强这个老词，会重新变得体面
“渐进增强”这个词也很有年代感。它不像“AI Native”那样时髦，也不像“全栈框架”那样威风。它听起来像一个脾气温和的老工程师，说话不大声，但每句话都能落地。
渐进增强的意思其实很简单：基础内容先成立，交互能力再增强。
表单先是一个表单，然后再增强校验和提交体验；弹层先考虑 <dialog>，再考虑复杂封装；展开收起先想想 details/summary；图片懒加载先用 loading="lazy"；请求交互可以用 Fetch 增强，但不必把所有链接和表单都消灭掉。
这套思路在 AI 时代很有价值。因为 AI 读一个页面时，如果基础行为已经写在 HTML 里，它就不必先穿过一整套状态机、事件系统和框架生命周期，才能猜出页面想干什么。
换句话说，渐进增强让页面的意图暴露在更表层的地方。人容易看，机器也容易看。维护者少受罪，后来接手的 AI 也少胡猜。
我越来越觉得，好的前端代码应该像一份清楚的说明书，而不是一间密室。密室也有趣，但不能每个页面都是密室逃脱。
古早 Web 会回来，但会带着新零件
说到这里，容易给人一种印象：我们是不是要回到古早 Web？我的看法是，会，也不会。
会，是因为早期 Web 的一些核心东西会回来：文档、链接、表单、服务端输出、缓存、语义化结构、少量脚本、直接稳定的页面。它们过去看起来土，是因为那时工具弱、协作难、工程能力不足。很多混合开发方式不是思想不对，而是当年条件不够。
不会，是因为这一次不是原样返回。
今天我们有现代 CSS，有 Fetch，有 Web Components，有原生表单能力，有 <dialog>，有 Popover API，有更成熟的可访问性标准，有静态生成，有边缘计算，有更好的部署平台，还有 AI。
AI 尤其重要。它能帮助我们生成模板、整理内容、补全语义、检查结构、重构样式、连接 API。过去混合开发最怕碎片化，现在 AI 可以在一定程度上帮我们管理这些碎片。于是，那些曾经被大框架遮住的简单方案，重新有了上桌的资格。
这就像时尚轮回。回来的不是当年那件旧衣服，而是同一种剪裁，换了新材料。前端也一样。回来的不是低水平页面拼接，而是以语义化为骨架、以高性能为默认、以渐进增强为方法、以机器友好为目标的新 Web。
前端工程师要重新学会判断
AI 会让写代码更容易，但不会自动让系统更合理。恰恰相反，代码越容易生成，判断就越重要。
未来前端工程师的价值，可能不只是熟悉某个框架 API，而是知道什么时候不该上复杂方案；知道一个页面应该怎样组织内容；知道哪些交互应该交给浏览器，哪些才需要 JavaScript；知道怎样输出对人、搜索引擎、辅助技术和 AI 都友好的结构。
也就是说，前端工程师要重新学会判断边界。
复杂应用是一条路，内容与轻交互页面是另一条路。前者仍然需要重型架构，后者则会越来越倾向于语义化、轻运行时、服务端或边缘输出、渐进增强。过去我们喜欢把两条路混在一起，拿最复杂的工具去处理最朴素的问题。AI 时代，也许终于可以把它们分清楚。
这不是因为我们变保守了，而是因为我们选择更多了。
当 AI 能快速生成和维护不同技术形态时，我们没必要为了统一而统一。真正应该统一的是结果：页面更快，结构更清楚，内容更容易被理解，用户体验更好。
结语
前端不会因为 AI 而消失。它只会被迫重新回答一个老问题：Web 到底是什么？
如果 Web 只是一个运行 JavaScript 应用的容器，那前端当然会继续变重。但如果 Web 还是文档、链接、语义、表单、可访问性、性能和开放协议的集合，那么前端就有机会走向另一种方向。
这种方向看起来有点古早，但古早不等于倒退。
时尚是一个轮回，前端也是一个轮回。只不过这一轮，我们不是退回原点，而是带着 AI、现代浏览器能力、边缘计算和自动化工具，再次出发。
也许下一代高性能网站开发的起点，不在某个更重的框架里，而在一个更清楚的 HTML 结构里。
