前端开发的"小行星撞击时刻"：AI 正在重塑这个领域

译注：本文翻译自 Nolan Lawson 于 2026 年 8 月 23 日发表在其个人博客 Read the Tea Leaves 上的文章《The asteroid currently hitting frontend web development》。Nolan Lawson 曾任职于微软 Edge 浏览器性能团队，长期关注 Web 标准、浏览器性能与可访问性。原文链接见文末。

教育者们正在退场

Nolan Lawson 在文章开头指出，他欣赏的许多前端教育者要么退出，要么大幅缩减投入，包括 Axel Rauschmayer、Salma Alam-Naylor、Josh W. Comeau 等人。而 Kent C. Dodds、Addy Osmani、Rachel Nabors、Lydia Hallie 等知名人物，也已从讨论前端开发转向讨论 AI 相关话题。

Lawson 本人并不靠讲前端谋生，但他运营着这个博客，也做过会议演讲和播客。他近期热衷的主题是 CSS 性能的方方面面：shadow DOM 如何工作、浏览器样式引擎如何运作、CSS-in-JS 的陷阱等。

一次实验：把 Chrome trace 交给 Claude

为了验证 AI 的能力边界，Lawson 向 Claude Sonnet 提了一个他最喜欢的技术难题：面对一份 Chrome trace，其中反复出现高 "Style" 开销但 Layout 开销相对较低，应该从哪些方面排查优化？

Claude 给出了一份相当完整的回答，涵盖：

• 选择器复杂度与数量：深层嵌套、后代组合器、通配符与属性选择器、CSS-in-JS 生成的大量唯一类名
• 失效范围（invalidation scope）：在 DOM 树高处切换 class/attribute/style 会强制大范围子树重算样式，建议使用 Chrome DevTools 的 "Selector Stats"
• 频率与放大效应：每帧多次触发样式重算、循环中读取样式属性导致同步重算、未批量的 DOM 变更
• 继承/计算属性传播：修改祖先的继承属性或 CSS 自定义属性会波及所有后代
• Shadow DOM / 组件边界：非共享样式表可能导致每个组件实例重复重算

Claude 还给出了后续测量建议（启用 Selector Stats、检查 Recalculate Style 的调用栈、统计受影响元素数量、查找强制同步样式）以及典型修复手段（缩小状态切换范围、简化选择器、批量 DOM 变更、使用 content-visibility: auto 或 contain 限制失效范围）。

Lawson 坦言，即便自己写过多年浏览器性能文章、甚至在浏览器性能团队工作过，如今面对一个加载缓慢的网站，他很可能也会直接把 Chrome trace 丢给 Claude Code 让它提改进建议——而且他在本职工作中已经这么做过，效果不错。

前端未来的三个不利趋势

Lawson 认为，有几个趋势正在削弱对前端知识投资的回报：

1. 前端交给 agent 的风险更低。 数据库迁移这类操作通常需要多轮 AI 代码审查、人工复核、先在 staging 跑一遍；但让 agent 写一个 React 组件然后直接上线，风险通常低得多。前端代码更具临时性和可替换性，因此许多 AI 编码者会放心让 agent 无人监督地处理。

2. DevExp 的整体重要性在下降。 前 LLM 时代，前端圈大量讨论围绕"人体工学 vs 结果"展开，比如 Alex Russell 的《The 'developer experience' bait-and-switch》。Svelte 和 Solid 长期主张其人体工学能带来比 React 更好的结果。但 Cursor 和 Viget 分别将代码库从 Solid 和 Lit 迁移到 React——原因很明确："agent 更懂 React"。React 在训练权重中被严重过度代表，"agent experience" 开始比 developer experience 更重要。

3. 标准演进方向会改变。 Lawson 推测，改善建站人体工学的努力（更好的 CSS 简写、更简洁的 JS 语法）相对于真正提升性能和能力的特性，重要性会被重新评估。毕竟让 agent 写 3 行 CSS 还是 1 行差别不大，而使用新语法反而可能更难，因为需要额外指导 agent 了解其训练权重中没有的东西。

他回忆起多年前在 TPAC 上，一位 Chrome 团队成员曾表示对 Web Component 标准不感兴趣，因为这些 API 只影响开发者体验，并未真正让浏览器能力更强（如 Project Fugu）。这个观点一直留在他心里：shadow DOM 和 custom elements 并未赋予 Web 开发者新超能力，只是改变了代码编写的位置和方式。

前端教育可能的出路

Lawson 提出了三个相对积极的方向：

第一，agent 仍然需要被"教育"大局观。 Agent 和 harness 似乎偏爱写 React 尤其是 SPA，但 SPA 并非万能。为营销站点让 agent 写一个复杂 SPA，再修复后退按钮、焦点状态、性能等 bug，可能消耗大量 token；不如直接选择 Astro 或 Eleventy 这类 MPA 框架。虽然 agent 用这些框架可能稍难（尤其 Astro 看起来像 React 但并不是），但整体代码量少约 50%，这点困难可能无关紧要。

第二，让网站对 agent 友好，在近期可能是有价值的方向。 Vercel 的 is-agentic 是一个例子。这反而指向了面向公众的网站本就该做好的基本功：服务端渲染内容、良好的可访问性、页面速度等。

第三，为"vibe-coded"的产物提供咨询服务。 大量 AI 生成的前端代码正在涌入，其中一部分会成为"承重结构"。如果这些网站缓慢、不合规、充满安全漏洞，仅靠对 agent 说"帮我修网站"可能不够。这里可能存在真正专业知识的空间。

结语：小行星已经撞击

Lawson 表示，这篇文章不是为了自我安慰，也不是在那些被 AI 冲击的职业坟头上跳舞。他天性悲观，这篇文章是允许自己沉浸在阴郁中。他指出，一些博客中弥漫着"我受够了谈论 AI"的情绪，其中一部分是世故的超然姿态，但很多来自真实的恐惧——承认自己不知道一年后会发生什么，是件可怕的事。

他使用的隐喻是：一颗小行星刚刚撞击地球，我们仍在勘察残骸。尘埃落定后会怎样很难预测，但完全无视这个陨石坑，是最糟糕的否认。另一个隐喻是新冠：当新冠来袭时，他不会想"天啊我受够了谈论新冠"，而是想尽可能了解病毒、流行病学、口罩等知识——这后来被证明是好主意。

Lawson 承认自己如今在这个领域的利害关系少了很多：他已离开 Web 标准领域，当前工作也不做前端，博客内容大多变成了对 AI 的哀叹。但他仍然对前端领域怀有热爱与尊重，关心它的未来。几年后它可能面目全非，但无论如何，他希望同行们能找到穿越这些变化的方式，在这个奇怪的新世界中茁壮成长。

评论区观点

文章引发了 21 条回应。有读者 Rob Mathews 直言"前端开发已死"。读者 Sander van Dragt 则提出不同看法：他认为把这样一个对普通 Web 开发者而言相当深入的技术问题交给 AI，从中能学到很多，但作者却得出"太容易直接问 agent"的结论，这让他意外。他建议应该让 AI 帮助学习、追问答案的利弊、从不同角度审视、要求举例，而不是把它当作更好的 Stack Overflow 来获取即用答案。

Lawson 回应表示部分认同，并补充说教育者面临的挑战在于：面对"简单按钮"，很多人会直接点击而不愿下功夫；同时 agent 已经是极好的老师，无限耐心且能针对学生的具体问题调整。他还指出，自己不会止步于问 agent 一个问题，而是会把 Chrome trace、源代码和浏览器都交给它，让它写 benchmark 并迭代解决方案。在可以输入"让它变快"、几分钟后就得到证明代码 A 比代码 B 更快的 benchmark 的世界里，很难论证投资学习这些分析方法的必要性——当然，agent 仍会幻觉、遗漏，判断力暂时仍有价值。

读者 Quebo 则持相反意见，认为后端更确定、更容易被 AI 接管，而前端更难，要处理屏幕尺寸、颜色、分辨率以及最难的"人眼"；前端的弱点是所有人都能看见并发表意见，连 CEO 和高管都能看出卡片没对齐。

原文链接

https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/