The asteroid currently hitting front end web development

Home Apps Code Talks About 23 Aug The asteroid currently hitting frontend web development Posted August 23, 2026 by Nolan Lawson in Web. Tagged: AI. 14 Comments A lot of the educators I admire in the frontend web space seem to be either bowing out or dialing back their efforts: Axel Rauschmayer, Salma Alam-Naylor, Josh W. Comeau, to name a few. Other well-known luminaries like Kent C. Dodds, Addy Osmani, Rachel Nabors, and Lydia Hallie have pivoted from talking about frontend development to talking about… well, take a wild guess. I never made a living from talking about web dev, but I do have this blog, and I’ve done conference talks and podcasts about stuff I’m excited about. Recently for example, my passion was explaining all the ins and outs of CSS performance: how shadow DOM works, how the browser’s style engine works, the traps of CSS-in-JS, etc. Just for kicks, I decided to ask Claude Sonnet how it would handle a Chrome trace with high “Style Calculation” costs. This is one of my favorite brain-teasers, because it’s the kind of thing that I saw web devs – even experienced ones! – trip up on over and over again. Claude gave a perfectly admirable answer: Prompt: Answer without searching the internet: you’re looking at a Chrome trace, and you see repeated spans of high Style cost but relatively low Layout cost. What kind of things do you look for in the webapp to optimize? What do you measure next? Prompt: Answer without searching the internet: you’re looking at a Chrome trace, and you see repeated spans of high Style cost but relatively low Layout cost. What kind of things do you look for in the webapp to optimize? What do you measure next? What “Style” cost actually represents The Style (Recalculate Style) phase is where the browser matches CSS selectors against the DOM and computes the final computed style for each affected element. It’s expensive independent of whether anything actually moves or resizes (that’s Layout’s job). So if Style is high but Layout is low, you’re likely paying for selector matching / invalidation over many elements, not for expensive geometry. What to look for in the webapp 1. Selector complexity and count Overly complex or deeply nested selectors (.a .b .c >; .d + .e), especially descendant combinators, force the engine to walk more of the DOM/ancestor chain per match attempt. Universal selectors or attribute selectors ([data-foo="bar"]) applied broadly. CSS-in-JS libraries that generate huge numbers of unique class names/rules (style recalculation has to consider the whole rule set). 2. Invalidation scope — this is usually the big one A class/attribute/style toggle high up in the DOM tree (e.g., toggling a class on or a top-level container) can force style recalculation on large subtrees even if only a few elements’ final styles change. Check whether a single state change (e.g., a “theme” class, a “loading” class, a hover state) is invalidating far more elements than necessary. Chrome’s “Selector Stats” (enable in DevTools Performance settings) will show you which selectors are slow and how many elements they were tested against — this is the single most useful next measurement. 3. Frequency/amplification Something re-triggering style recalc many times per frame — e.g., reading a style/layout property in a loop right after a class change (forces synchronous recalc), or a JS animation using .classList.toggle() or inline style updates on many nodes per rAF tick instead of batching. Repeated small DOM mutations each forcing a style pass rather than being batched into one. 4. Inherited/computed property propagation Changing an inherited property (like font-size or color on a common ancestor) forces recompute of all descendants’ computed styles, even without layout changes (e.g., color, visibility, cursor are Style-only, not Layout-triggering). Custom properties (CSS variables) changed at a high-level scope — updating a --custom-prop on :root or a shared ancestor recomputes style for every element referencing it. 5. Shadow DOM / component boundaries If using a framework with lots of shadow roots or scoped styles, check whether style recalculation is being needlessly repeated per component instance due to non-shared stylesheets. What to measure next Enable “Selector Stats” in the Performance panel (gear icon → Enable selector stats). Re-record the trace. This gives you, per Recalculate Style event, the top slow selectors and match counts — that tells you directly which CSS rules and how many elements are responsible. Check the “Recalculate Style” event’s initiator/call stack in the trace to see what JS triggered it — a class toggle, a style.setProperty, an animation frame callback, etc. Count how many elements are affected per recalc — DevTools shows “Elements Affected” per Recalculate Style event in the summary pane. Compare that number to how many elements actually changed appearance — a big gap indicates over-broad invalidation. Look at where in the DOM the triggering mutation happens — is it near the root (broad invalidation) vs. scoped to a small subtree (narrow, cheap)? Check for forced synchronous style — look for “Forced reflow” purple warnings; even though you said Layout is low, sometimes a forced style read (getComputedStyle) interleaved with a DOM write shows up as many small back-to-back Style events rather than one batched one. Typical fixes once you find the culprit Scope class/state toggles to the smallest subtree possible instead of a common ancestor. Simplify selectors, prefer single class selectors over descendant chains. Move CSS custom property updates to the smallest scope needed. Batch DOM/class changes so recalculation happens once, not per-mutation. Use content-visibility: auto or contain: style layout on independent subtrees to limit invalidation scope. What “Style” cost actually represents The Style (Recalculate Style) phase is where the browser matches CSS selectors against the DOM and computes the final computed style for each affected element. It’s expensive independent of whether anything actually moves or resizes (that’s Layout’s job). So if Style is high but Layout is low, you’re likely paying for selector matching / invalidation over many elements, not for expensive geometry. What to look for in the webapp 1. Selector complexity and count Overly complex or deeply nested selectors (.a .b .c >; .d + .e), especially descendant combinators, force the engine to walk more of the DOM/ancestor chain per match attempt. Universal selectors or attribute selectors ([data-foo="bar"]) applied broadly. CSS-in-JS libraries that generate huge numbers of unique class names/rules (style recalculation has to consider the whole rule set). 2. Invalidation scope — this is usually the big one A class/attribute/style toggle high up in the DOM tree (e.g., toggling a class on or a top-level container) can force style recalculation on large subtrees even if only a few elements’ final styles change. Check whether a single state change (e.g., a “theme” class, a “loading” class, a hover state) is invalidating far more elements than necessary. Chrome’s “Selector Stats” (enable in DevTools Performance settings) will show you which selectors are slow and how many elements they were tested against — this is the single most useful next measurement. 3. Frequency/amplification Something re-triggering style recalc many times per frame — e.g., reading a style/layout property in a loop right after a class change (forces synchronous recalc), or a JS animation using .classList.toggle() or inline style updates on many nodes per rAF tick instead of batching. Repeated small DOM mutations each forcing a style pass rather than being batched into one. 4. Inherited/computed property propagation Changing an inherited property (like font-size or color on a common ancestor) forces recompute of all descendants’ computed styles, even without layout changes (e.g., color, visibility, cursor are Style-only, not Layout-triggering). Custom properties (CSS variables) changed at a high-level scope — updating a --custom-prop on :root or a shared ancestor recomputes style for every element referencing it. 5. Shadow DOM / component boundaries If using a framework with lots of shadow roots or scoped styles, check whether style recalculation is being needlessly repeated per component instance due to non-shared stylesheets. What to measure next Enable “Selector Stats” in the Performance panel (gear icon → Enable selector stats). Re-record the trace. This gives you, per Recalculate Style event, the top slow selectors and match counts — that tells you directly which CSS rules and how many elements are responsible. Check the “Recalculate Style” event’s initiator/call stack in the trace to see what JS triggered it — a class toggle, a style.setProperty, an animation frame callback, etc. Count how many elements are affected per recalc — DevTools shows “Elements Affected” per Recalculate Style event in the summary pane. Compare that number to how many elements actually changed appearance — a big gap indicates over-broad invalidation. Look at where in the DOM the triggering mutation happens — is it near the root (broad invalidation) vs. scoped to a small subtree (narrow, cheap)? Check for forced synchronous style — look for “Forced reflow” purple warnings; even though you said Layout is low, sometimes a forced style read (getComputedStyle) interleaved with a DOM write shows up as many small back-to-back Style events rather than one batched one. Typical fixes once you find the culprit Scope class/state toggles to the smallest subtree possible instead of a common ancestor. Simplify selectors, prefer single class selectors over descendant chains. Move CSS custom property updates to the smallest scope needed. Batch DOM/class changes so recalculation happens once, not per-mutation. Use content-visibility: auto or contain: style layout on independent subtrees to limit invalidation scope. These days, given a slow-loading website, even as someone who’s written about browser performance for years and who literally worked on a browser performance team, I would probably just chuck a Chrome trace at Claude Code and have it suggest improvements. In fact I’ve done this very thing in my day job and gotten some good results. The future of frontend So where does this leave frontend dev education? Not in a great place obviously; I wish I had some more uplifting answers for people who (like me) used to get a lot of fulfillment out of trying to raise the bar for frontend developers everywhere. I do have some guesses though, and I think the problem is still worth puzzling through. The core question is where frontend development itself lands in this new era. Sadly it feels to me like there are several trends pointing against increased investment in frontend knowledge: The frontend is less risky to just hand to an agent. If you’re using an agent to write a database migration, you probably want to put it through several rounds of AI code review, scrutinize it yourself, run it on staging first, etc. If you write a React component with an agent, though, then the risk of just yolo’ing it into production is (typically) much lower. Note I’m not saying there are zero risks: the agent could mess up accessibility, it could cause an infinite loop that blocks users, etc. But in general, frontend code is a lot more ephemeral and replaceable than other types of code. So I expect many AI coders will feel comfortable just letting their agent handle it unsupervised (for better or worse). DevExp is becoming less critical overall. A lot of the pre-LLM discussion in the frontend space was about ergonomics versus outcomes: “The ‘developer experience’ bait-and-switch” by Alex Russell is a great example. For another example, Svelte and Solid have long argued that their ergonomics lead to better outcomes than React: less code, better performance, etc. Meanwhile, Cursor and Viget have blogged about migrating their codebases from Solid and Lit, respectively, to React. Since rewrites are less expensive with agents, this may be a bit surprising: why not move to the more performant/less verbose framework? The answer (explicitly in Cursor’s case, and I suspect for Viget as well) is of course: “the agents know React.” For better or worse, React is heavily overrepresented in the training weights, and “agent experience” is starting to matter more than developer experience. Standards will catch up. I’ve been out of the web standards space for a couple years now, so this is pure speculation on my part. But I imagine that a lot of the efforts to improve the ergonomics of building websites – better CSS shorthands, terser JavaScript syntax, etc. – will become perceived as less important relative to things that actually move the needle on performance, capabilities, etc. At the end of the day, it’s just not very different for an agent to write 3 lines of CSS instead of 1, and anyway using the newer syntax might actually be harder because you have to coach the agent about things that aren’t in its training weights. In some ways this shift might have already been underway. I remember several years ago at TPAC, well before the AI coding boom, I told someone on the Chrome team that I was working on web component standards. They responded that they weren’t interested in that, because those APIs only affected the developer experience and didn’t actually make the browser more capable (e.g. Project Fugu). That stuck with me because it’s a good point: APIs like shadow DOM and custom elements don’t give web developers any new superpowers; they just change where and how the code gets authored. I expect such things will move out of the spotlight as AI coding takes over. This doesn’t mean that standards will disappear from the topics a frontend dev needs to keep up on, but I imagine it will become less about “use this newer syntax” (an evergreen source of material for conference talks and articles) and more “here are these emerging capabilities.” And I predict the latter group will be much smaller than the former, since they tend to be more contentious for standards bodies and there’s just a smaller pool of features to draw from. Whither frontend education? So how can the field of frontend education adapt to this hostile future? To avoid being utterly bleak, here are some positive directions I think it could go in. First off, the agents still need to be educated about the big picture. Agents and harnesses seem to love writing React and specifically SPAs, but SPAs are not the answer to everything. You can burn a lot of tokens having an agent write a big complex SPA for your marketing site, and then fix all the bugs with the back button, focus state, performance, etc., or you can just choose an MPA framework like Astro or Eleventy and call it a day. Maybe these frameworks will be a bit harder for the agents to work with (specifically Astro since it kinda-sorta looks like React but isn’t), but my guess is that since you’re writing ~50% less code overall it won’t matter. Second, making websites that work well for agents is probably going to be a fruitful endeavor for the near future. Vercel’s is-agentic is a good example of this. Ironically, this points back to good fundamentals that public-facing websites should have been doing anyway: server-rendered content, proper accessibility, page speed, etc. But if slapping the word “AI” on it is what gets people to care about it then hey, I’m all for it. Note that I’m a little bit less sanguine about this second point, because I’m not sure the web even survives in its current form as agents become more of a thing. If I want to figure out how much it costs to fly from Seattle to Paris, I’d much rather ask an agent than click through an infuriating series of buttons on a slow-loading website. The only reason I can’t is because these websites explicitly block bots, or they don’t offer an MCP, but I’m sure there are several startups champing at the bit to solve that problem. So I’m not sure how sustainable the current situation is. Third, we can offer consulting services for vibe-coded monstrosities. A massive amount of AI-generated frontend code is being pumped out right now, and some of it (to use a Claude-ism) will certainly become “load-bearing.” If those websites are slow, non-compliant, and riddled with security holes, then it may not be enough to ask the agent “fix my website pls.” There could be an opportunity here for real expertise, especially if there’s money on the line and the vibe coder’s knowledge of web development doesn’t extend past “websites are apps hosted on the internet.” (I acknowledge that this is the shakiest of my three points, since I can totally imagine the next generation of “self-healing” web apps to eclipse the average expert in 2027 or 2028. But for the time being: yes, expertise still matters.) Conclusion The point of this post wasn’t to make myself feel better, or to dance on the graves of all the careers that have been upended by the recent AI boom. I’m a naturally gloomy person, and this post was me allowing myself to wallow in my own gloominess. I don’t take any pleasure from noting that the huge body of knowledge I’ve built up over the years has been rendered nearly obsolete, nor am I happy to see the same thing happen to my much-more-qualified peers. But pretending that it’s not happening isn’t a valid strategy either. There’s a mood in some of the blogs I read these days along the lines of “I’m so tired of talking about AI” or “Please don’t mention AI to me ever again.” I’m sure some of this is a kind of world-weary, above-it-all air that feels good to wear as a badge of distinction. But I think a lot of it also comes from real fear. It’s scary to admit that you don’t know what’s going to happen in a year. It’s destabilizing to imagine your career going along a certain trajectory, serenely landing at retirement, and then to see everything upset just a few years from your goal. The metaphor I’ve been using is that an asteroid just hit the earth, and we’re still surveying the wreckage. It’s hard to predict what will happen after the dust settles (let alone which tiny rodents will usher in the Age of Mammals!), but ignoring the crater altogether seems like the worst kind of denial. Another metaphor is covid: when covid hit, I don’t recall thinking, “Ugh, I’m so tired of talking about covid” – instead, I wanted to learn everything I could about viruses, epidemiology, masking, etc. This turned out to be a good idea, since covid was going to dominate my life for the next few years (at which point yes, I did finally get tired of talking about it!). I hardly have a crystal ball, but this post was my attempt to think through where my most cherished field might be going in the future. I admit that I have a lot less skin in the game these days: I’m out of web standards, I don’t even work on the frontend at my current gig, and my blog has mostly been a lot of wailing and gnashing of teeth about AI rather than my usual menu of browsers, performance, accessibility, etc. That said, I still have a lot of love and respect for the frontend field, and I care about what happens to it in the future. It may be unrecognizable in just a few years, but if nothing else, I hope my peers find a way to navigate all these changes and to thrive in this weird new world. Related 14 responses to this post. Posted by Short notes on tech 35/2026 - Rule of Tech on August 28, 2026 at 12:49 AM […] The asteroid currently hitting frontend web developmentGreat writeup of how AI affect frontend web development. “The core question is where frontend development itself lands in this new [AI] era. Sadly it feels to me like there are several trends pointing against increased investment in frontend knowledge” tl;dr; The frontend is less risky to just hand to an agent.; DevExp is becoming less critical overall.; DevExp is becoming less critical overall. […] Reply Posted by Short notes on tech 35/2026 - Rule of Tech on August 28, 2026 at 12:49 AM […] The asteroid currently hitting frontend web developmentGreat writeup of how AI affect frontend web development. “The core question is where frontend development itself lands in this new [AI] era. Sadly it feels to me like there are several trends pointing against increased investment in frontend knowledge” tl;dr; The frontend is less risky to just hand to an agent.; DevExp is becoming less critical overall.; DevExp is becoming less critical overall. […] Reply Posted by The asteroid currently hitting front end web development — Getlan on September 3, 2026 at 12:37 PM […] Источник: Hacker News […] Reply Posted by The asteroid currently hitting front end web development — Getlan on September 3, 2026 at 12:37 PM […] Источник: Hacker News […] Reply Leave a comment Cancel reply Δ This site uses Akismet to reduce spam. Learn how your comment data is processed. Recent Posts On not becoming a cyborg The asteroid currently hitting frontend web development You can just choose how many bugs you want now Using AI to write better code more slowly The diminished art of coding About Me I'm Nolan, a programmer from Seattle working at Socket. All opinions are my own. Photo by Cătălin Mariș. Archives August 2026 (3) May 2026 (1) March 2026 (1) February 2026 (4) January 2026 (2) December 2025 (4) November 2025 (1) August 2025 (1) June 2025 (1) April 2025 (1) January 2025 (1) December 2024 (2) October 2024 (2) September 2024 (3) August 2024 (1) July 2024 (1) March 2024 (1) January 2024 (1) December 2023 (4) August 2023 (2) January 2023 (2) December 2022 (1) November 2022 (2) October 2022 (2) June 2022 (4) May 2022 (3) April 2022 (1) February 2022 (1) January 2022 (1) December 2021 (3) September 2021 (1) August 2021 (6) February 2021 (2) January 2021 (2) December 2020 (1) July 2020 (1) June 2020 (1) May 2020 (2) February 2020 (1) December 2019 (1) November 2019 (1) September 2019 (1) August 2019 (2) June 2019 (4) May 2019 (3) February 2019 (2) January 2019 (1) November 2018 (1) September 2018 (5) August 2018 (1) May 2018 (1) April 2018 (1) March 2018 (1) January 2018 (1) December 2017 (1) November 2017 (2) October 2017 (1) August 2017 (1) May 2017 (1) March 2017 (1) January 2017 (1) October 2016 (1) August 2016 (1) June 2016 (1) April 2016 (1) February 2016 (2) December 2015 (1) October 2015 (1) September 2015 (1) July 2015 (1) June 2015 (2) October 2014 (1) September 2014 (1) April 2014 (1) March 2014 (1) December 2013 (2) November 2013 (3) August 2013 (1) May 2013 (3) January 2013 (1) December 2012 (1) November 2012 (1) October 2012 (1) September 2012 (3) June 2012 (2) March 2012 (3) February 2012 (1) January 2012 (1) November 2011 (1) August 2011 (1) July 2011 (1) June 2011 (3) May 2011 (2) April 2011 (4) March 2011 (1) Tags Links Mastodon GitHub npm Blog at WordPress.com.