当前前端Web开发的巨变

Hacker News Top 新闻
frontend-development css-performance web-development ai-tools tech-trends developer-education

摘要

文章探讨了前端Web开发领域中有影响力的教育者的离职，并突出了Claude Sonnet等AI工具处理复杂技术问题的能力，预示着科技格局的转变。

暂无内容
查看原文
查看缓存全文

缓存时间: 2026/09/03 21:00

# 正在冲击前端网页开发的小行星 来源：https://nolanlawson.com/2026/08/23/the-asteroid-currently-hitting-frontend-web-development/ 我所敬佩的许多前端网页领域教育者，似乎都在逐渐淡出或减少投入：例如Axel Rauschmayer (https://exploringjs.com/)、Salma Alam-Naylor (https://whitep4nth3r.com/blog/goodbye-forever-probably/)、Josh W. Comeau (https://bsky.app/profile/joshwcomeau.com/post/3mkxyqfwwm22t)。其他知名专家，如Kent C. Dodds (https://kentcdodds.com/)、Addy Osmani (https://addyosmani.com/)、Rachel Nabors (https://nearestnabors.com/) 和 Lydia Hallie (https://x.com/lydiahallie)，也已从讨论前端开发转向讨论……嗯，你大可以猜猜看。 我从未靠谈论网页开发谋生，但我有这个博客，也曾在会议和播客中谈论我热衷的主题。例如，最近我的热情是解释CSS性能的方方面面：Shadow DOM的工作原理 (https://nolanlawson.com/2022/06/22/style-scoping-versus-shadow-dom-which-is-fastest/)、浏览器样式引擎的工作原理 (https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-performance/)、CSS-in-JS的陷阱 (https://nolanlawson.com/2022/10/22/style-performance-and-concurrent-rendering/) 等等。 纯粹为了好玩，我决定问问Claude Sonnet如何处理具有高“样式计算”开销的Chrome跟踪记录。这是我最喜欢的思考题之一，因为这种问题我见过许多网页开发者——甚至是经验丰富的开发者！——一再犯错。 Claude给出了一个完全令人钦佩的回答：点击查看> **提示：** 无需上网搜索：你正在查看一个Chrome跟踪记录，其中看到反复出现的高样式开销但相对较低的布局开销。你会在网页应用中寻找什么来优化？接下来会测量什么？ ## “样式”开销实际代表什么 **样式（重新计算样式）** 阶段是浏览器将CSS选择器与DOM匹配，并计算每个受影响元素的最终计算样式的阶段。这个过程开销很大，无论元素是否实际移动或调整大小（那是布局的工作）。因此，如果样式开销高但布局开销低，你很可能是在为**在大量元素上的选择器匹配/失效**付出代价，而不是为**昂贵的几何计算**付出代价。 ## 在网页应用中应关注什么 **1. 选择器复杂性和数量** - 过于复杂或嵌套过深的选择器（例如 `.a .b .c > .d + .e`），尤其是后代组合器，会强制引擎在每次匹配尝试时遍历更多DOM/祖先链。 - 被广泛使用的通用选择器或属性选择器（如 `[data-foo="bar"]`）。 - 生成大量唯一类名/规则的CSS-in-JS库（样式重新计算必须考虑整个规则集）。 **2. 失效范围——这通常是关键** - 在DOM树高处（例如在`<body>`或顶级容器上）切换一个类/属性/样式，即使只有少数元素的最终样式改变，也可能强制对大量子树进行样式重新计算。 - 检查单一状态变化（例如“主题”类、“加载”类、悬停状态）是否导致远超必要的元素失效。Chrome的“选择器统计信息”（在开发者工具性能设置中启用）会向你显示哪些选择器运行缓慢以及它们针对了多少个元素进行测试——这是接下来最有用的单项测量。 **3. 频率/放大效应** - 某些东西在每帧内多次重新触发样式重新计算——例如，在类更改后立即在循环中读取样式/布局属性（强制同步重新计算），或使用`classList.toggle()`或在每一帧回调中对许多节点进行内联`style`更新而不是批量处理的JavaScript动画。 - 重复进行小型DOM变更，每次强制执行一次样式遍历，而不是批量合并为一次。 **4. 继承/计算属性传播** - 更改继承属性（如在常见祖先上设置`font-size`或`color`）会强制重新计算所有后代的计算样式，即使没有布局更改（例如，`color`、`visibility`、`cursor`仅触样式，不触发布局）。 - 在高级别作用域更改自定义属性（CSS变量）——更新`:root`或共享祖先上的`--custom-prop`会重新计算每个引用它的元素的样式。 **5. Shadow DOM / 组件边界** - 如果使用了具有大量shadow根或作用域样式的框架，请检查样式重新计算是否因为样式表不共享而被不必要地为每个组件实例重复执行。 ## 接下来该测量什么 1. **在性能面板中启用“选择器统计信息”**（齿轮图标 → 启用选择器统计信息）。重新记录跟踪。这会向你提供每个“重新计算样式”事件对应的最慢选择器和匹配次数——这会直接告诉你哪些CSS规则以及多少个元素是问题的根源。 2. **在跟踪中检查“重新计算样式”事件的发起者/调用栈**，看看是什么JavaScript触发了它——类切换、`style.setProperty`、动画帧回调等。 3. **计算每次重新计算影响了多少个元素**——开发者工具在摘要窗格中为每个“重新计算样式”事件显示“受影响的元素”。将这个数字与*实际*改变外观的元素数量进行比较——巨大差距表明失效范围过广。 4. **查看触发变更在DOM中的位置**——是在根节点附近（广泛失效）还是局限于小子树（范围窄，开销低）？ 5. **检查强制同步样式读取**——寻找“强制回流”紫色警告；即使你说布局开销低，有时一次强制的*样式*读取（如`getComputedStyle`）与DOM写入交错，会显示为许多连续的小型“样式”事件，而不是一次批量的。 ## 一旦找到罪魁祸首的典型修复方法 - 将类/状态切换的作用域限制在尽可能小的子树，而不是公共祖先。 - 简化选择器，优先使用单类选择器而非后代链。 - 将CSS自定义属性更新移至所需的最小作用域。 - 批量处理DOM/类变更，使重新计算发生一次，而不是每次变更都发生。 - 对独立的子树使用`content-visibility: auto`或`contain: style layout`来限制失效范围。 如今，面对一个加载缓慢的网站，即使像我这样多年撰写浏览器性能文章、并且*曾效力于浏览器性能团队*的人，可能也会直接把Chrome跟踪记录扔给Claude Code让它建议改进措施。事实上，我在日常工作中就这么做过，并且得到了不错的结果。 ## 前端的未来 那么，前端开发教育该何去何从？显然，处境不佳；我希望能给那些像我一样，曾因努力提升各地前端开发者水平而获得满足感的人一些更鼓舞人心的答案。不过，我确实有一些猜测，我认为这个问题仍然值得深入思考。 核心问题是前端开发本身在这个新时代中的定位。遗憾的是，在我看来，有几个趋势都不利于对前端知识的进一步投入： **前端风险较低，可以放心交给智能体处理。** 如果你使用智能体编写数据库迁移脚本，你可能会希望它经过多轮AI代码审查、自己仔细检查、先在预发布环境运行等等。但如果你用智能体编写一个React组件，那么直接将其投入生产的风险（通常）要低得多。注意，我*不是*说零风险：智能体可能会搞砸无障碍性、引发无限循环阻塞用户等。但总体而言，前端代码比其他类型的代码更短暂且更易替换。因此，我预计许多AI程序员会放心地让他们的智能体独立处理（无论好坏）。 **开发者体验（DevEx）整体上变得不那么关键了。** 前端领域在LLM之前的很多讨论都围绕人机工程学与结果之间的权衡：亚历克斯·罗素（Alex Russell）的“The developer experience bait-and-switch” (https://infrequently.org/2018/09/the-developer-experience-bait-and-switch/) 就是一个很好的例子。再举一例，Svelte和Solid长期主张它们的人机工程学比React带来更好的结果：更少的代码、更好的性能等。然而，Cursor (https://x.com/poteto/status/2089227731305464150) 和 Viget (https://www.viget.com/articles/using-ai-to-migrate-from-lit-to-react) 都在博客中讲述了将代码库分别从Solid和Lit迁移到React的经历。既然重写在智能体的帮助下成本更低，这可能有点令人惊讶：为什么不转向性能更好/更简洁的框架呢？答案（在Cursor的案例中是明确的，我怀疑Viget也是如此）当然是：“智能体们懂React。”无论好坏，React在训练权重中被严重过度代表，而“智能体体验”正开始比开发者体验更重要。 **标准将会迎头赶上。** 我离开网页标准领域已有几年，所以这纯属我的推测。但我想象，许多旨在改善构建网站人机工程学的努力——更好的CSS简写、更简洁的JavaScript语法等——相对于那些真正能提升性能、能力等方面的东西，其重要性会被认为降低了。归根结底，智能体写3行CSS和写1行CSS差别并不大，而且使用更新的语法实际上可能*更难*，因为你必须就其训练权重中没有的内容来指导智能体。 在某些方面，这种转变可能已经开始了。我记得几年前在TPAC (https://www.w3.org/wiki/TPAC)（远在AI编码兴起之前），我告诉Chrome团队的一个人我正在研究网页组件标准。他们回应说对此不感兴趣，因为这些API只影响开发者体验，并没有真正让浏览器更强大（例如Project Fugu (https://www.chromium.org/teams/web-capabilities-fugu/)）。这让我印象深刻，因为这是一个好观点：像Shadow DOM和自定义元素这样的API并没有给网页开发者任何新的超能力；它们只是改变了代码被编写的位置和方式。我预计随着AI编码接管，这些东西会逐渐淡出聚光灯。 这并不意味着标准会从前端开发者需要跟进的主题中消失，但我想象它会从“使用这个更新的语法”（一个为会议演讲和文章提供永恒素材的领域）转向“这里有这些新兴的能力”。而且我预测后者的数量会比前者少得多，因为它们往往在标准机构中更具争议性，并且可供选择的特性池本身就更小。 ## 前端教育将何去何从？ 那么，前端教育领域如何才能适应这个不友好的未来？为了避免过于悲观，这里是我认为它可能发展的几个积极方向。 首先，智能体仍然需要从大局角度接受教育。智能体和工具链似乎喜欢写React，特别是SPA，但SPA并非万能 (https://nolanlawson.com/2022/05/21/the-balance-has-shifted-away-from-spas/)。你可以耗费大量令牌让智能体为你的营销网站编写一个庞大复杂的SPA，然后修复所有关于后退按钮、焦点状态、性能等的漏洞；或者你可以直接选择一个MPA框架如Astro或Eleventy了事。也许这些框架对智能体来说更难处理（特别是Astro，因为它有点像React但又不是），但我猜由于你总体上编写了约50%的代码，这应该不重要。 其次，制作对智能体友好的网站在不久的将来可能是一个富有成效的尝试。Vercel的is-agentic (https://is-agentic.com/) 就是一个很好的例子。讽刺的是，这又回到了公共网站本就应具备的良好基础：服务器渲染的内容、适当的无障碍性、页面速度等。但如果贴上“AI”标签能让人们开始关注它，那么，嘿，我支持。 注意，我对第二点不那么乐观，因为我不确定随着智能体日益普及，网络是否还能以当前形式存续。如果我想了解从西雅图到巴黎的飞行成本，我宁愿询问智能体，也不愿在一个加载缓慢的网站上点击一系列令人恼火的按钮。我做不到的唯一原因是这些网站明确阻止机器人访问，或者它们不提供MCP（模型上下文协议），但我敢肯定有许多初创公司正迫不及待地想解决这个问题。所以我不确定当前状况的可持续性如何。 第三，我们可以为“氛围编码”产生的怪兽提供咨询服务。目前大量AI生成的前端代码正在涌现，其中一些（用Claude的术语）肯定会成为“承重”代码。如果这些网站速度慢、不合规、漏洞百出，那么仅仅要求智能体“请修复我的网站”可能不够。这里可能存在真正专业知识的机会，特别是当涉及真金白银，而氛围编码者对网页开发的理解仅限于“网站是托管在互联网上的应用”时。（我承认这是我的三点中最不牢靠的，因为我完全可以想象下一代“自愈”型网页应用会在2027或2028年超越普通专家。但就目前而言：是的，专业知识仍然很重要。） ## 结论 这篇文章的目的不是让我自己感觉好些，也不是在那些因最近AI浪潮而被颠覆的职业的坟墓上跳舞。我天性忧郁，这篇文章是我允许自己沉浸在阴郁情绪中的表现。我并不因为注意到自己多年积累的大量知识几乎变得过时而感到高兴，也不乐于看到比我资历更深厚的同行们遭遇同样的事情。但假装它没有发生也不是一个有效的策略。 最近我读到的一些博客中有一种情绪，类似“我厌倦了谈论AI”或“请再也不要跟我提AI了”。我确信其中一部分是一种看破红尘、超然物外的姿态，作为区别于他人的标志感觉不错。但我认为很大一部分也源于真实的恐惧。承认自己不知道一年后会发生什么是可怕的。想象自己的职业生涯沿着特定轨迹平静前行直至退休，却看到在临近目标时一切被颠覆，这种想象令人不安。我使用的比喻是，一颗小行星刚刚撞击了地球，而我们仍在评估残骸。尘埃落定后会发生什么（更不用说哪些小型啮齿动物将开启哺乳动物时代！）很难预测，但完全无视这个陨石坑似乎是最糟糕的否认。 另一个比喻是新冠疫情：当新冠来袭时，我不记得曾想过“呃，我厌倦了谈论新冠了”——相反，我想尽可能多地了解病毒、流行病学、口罩等等。事实证明这是个好主意，因为新冠将在未来几年主宰我的生活（是的，到了那时我确实最终厌倦了谈论它！）。 我几乎没有水晶球，但这篇文章是我试图思考我最珍视的领域未来可能走向何方的一次尝试。我承认如今我已不那么身在局中：我离开了网页标准领域，甚至不在当前工作中从事前端开发，我的博客也大多是对AI的哀叹与咬牙切齿，而非我惯常的浏览器、性能、无障碍等内容。也就是说，我仍然怀有很多的爱与热情……

相似文章

AI是否导致前端迷失十年的重演？

Hacker News Top

文章将当下AI对编程的去技能化作用与过去JavaScript框架对前端开发的去技能化现象进行了类比，认为两者都代表了向更高抽象层次的转变，这种转变降低了入门门槛，却削弱了工作者的议价能力。