{"id":23741,"date":"2026-08-23T23:36:05","date_gmt":"2026-08-23T23:36:05","guid":{"rendered":"https:\/\/scannn.com\/the-asteroid-currently-hitting-frontend-web-development\/"},"modified":"2026-08-23T23:36:05","modified_gmt":"2026-08-23T23:36:05","slug":"the-asteroid-currently-hitting-frontend-web-development","status":"publish","type":"post","link":"https:\/\/scannn.com\/lv\/the-asteroid-currently-hitting-frontend-web-development\/","title":{"rendered":"The asteroid currently hitting frontend web development"},"content":{"rendered":"\n<div>\n<p>A lot of the educators I admire in the frontend web space seem to be either bowing out or dialing back their efforts: <a href=\"https:\/\/exploringjs.com\/\">Axel Rauschmayer<\/a>, <a href=\"https:\/\/whitep4nth3r.com\/blog\/goodbye-forever-probably\/\">Salma Alam-Naylor<\/a>, <a href=\"https:\/\/bsky.app\/profile\/joshwcomeau.com\/post\/3mkxyqfwwm22t\">Josh W. Comeau<\/a>, to name a few. Other well-known luminaries like <a href=\"https:\/\/kentcdodds.com\">Kent C. Dodds<\/a>, <a href=\"https:\/\/addyosmani.com\/\">Addy Osmani<\/a>, <a href=\"https:\/\/nearestnabors.com\/\">Rachel Nabors<\/a>, and <a href=\"https:\/\/x.com\/lydiahallie\">Lydia Hallie<\/a> have pivoted from talking about frontend development to talking about\u2026 well, take a wild guess.<\/p>\n<p>I never made a living from talking about web dev, but I do have this blog, and I\u2019ve done conference talks and podcasts about stuff I\u2019m excited about. Recently for example, my passion was explaining all the ins and outs of CSS performance: <a href=\"https:\/\/nolanlawson.com\/2022\/06\/22\/style-scoping-versus-shadow-dom-which-is-fastest\/\">how shadow DOM works<\/a>, <a href=\"https:\/\/nolanlawson.com\/2023\/01\/17\/my-talk-on-css-runtime-performance\/\">how the browser\u2019s style engine works<\/a>, <a href=\"https:\/\/nolanlawson.com\/2022\/10\/22\/style-performance-and-concurrent-rendering\/\">the traps of CSS-in-JS<\/a>, etc.<\/p>\n<p>Just for kicks, I decided to ask Claude Sonnet how it would handle a Chrome trace with high \u201cStyle Calculation\u201d costs. This is one of my favorite brain-teasers, because it\u2019s the kind of thing that I saw web devs \u2013 even experienced ones! \u2013 trip up on over and over again. Claude gave a perfectly admirable answer:<\/p>\n<details>\n<summary>Click to see<\/summary>\n<p>\u00a0<\/p>\n<blockquote>\n<p><strong>Prompt:<\/strong> Answer without searching the internet: you\u2019re 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?<\/p>\n<\/blockquote>\n<blockquote>\n<h2>What \u201cStyle\u201d cost actually represents<\/h2>\n<p>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\u2019s expensive independent of whether anything actually moves or resizes (that\u2019s Layout\u2019s job). So if Style is high but Layout is low, you\u2019re likely paying for <strong>selector matching \/ invalidation over many elements<\/strong>, not for <strong>expensive geometry<\/strong>.<\/p>\n<h2>What to look for in the webapp<\/h2>\n<p><strong>1. Selector complexity and count<\/strong><\/p>\n<ul>\n<li>Overly complex or deeply nested selectors (<code>.a .b .c &gt;; .d + .e<\/code>), especially descendant combinators, force the engine to walk more of the DOM\/ancestor chain per match attempt.<\/li>\n<li>Universal selectors or attribute selectors (<code>[data-foo=\"bar\"]<\/code>) applied broadly.<\/li>\n<li>CSS-in-JS libraries that generate huge numbers of unique class names\/rules (style recalculation has to consider the whole rule set).<\/li>\n<\/ul>\n<p><strong>2. Invalidation scope \u2014 this is usually the big one<\/strong><\/p>\n<ul>\n<li>A class\/attribute\/style toggle high up in the DOM tree (e.g., toggling a class on <code>&lt;body&gt;<\/code> or a top-level container) can force style recalculation on large subtrees even if only a few elements\u2019 final styles change.<\/li>\n<li>Check whether a single state change (e.g., a \u201ctheme\u201d class, a \u201cloading\u201d class, a hover state) is invalidating far more elements than necessary. Chrome\u2019s \u201cSelector Stats\u201d (enable in DevTools Performance settings) will show you which selectors are slow and how many elements they were tested against \u2014 this is the single most useful next measurement.<\/li>\n<\/ul>\n<p><strong>3. Frequency\/amplification<\/strong><\/p>\n<ul>\n<li>Something re-triggering style recalc many times per frame \u2014 e.g., reading a style\/layout property in a loop right after a class change (forces synchronous recalc), or a JS animation using <code>.classList.toggle()<\/code> or inline <code>style<\/code> updates on many nodes per rAF tick instead of batching.<\/li>\n<li>Repeated small DOM mutations each forcing a style pass rather than being batched into one.<\/li>\n<\/ul>\n<p><strong>4. Inherited\/computed property propagation<\/strong><\/p>\n<ul>\n<li>Changing an inherited property (like <code>font-size<\/code> or <code>color<\/code> on a common ancestor) forces recompute of all descendants\u2019 computed styles, even without layout changes (e.g., <code>color<\/code>, <code>visibility<\/code>, <code>cursor<\/code> are Style-only, not Layout-triggering).<\/li>\n<li>Custom properties (CSS variables) changed at a high-level scope \u2014 updating a <code>--custom-prop<\/code> on <code>:root<\/code> or a shared ancestor recomputes style for every element referencing it.<\/li>\n<\/ul>\n<p><strong>5. Shadow DOM \/ component boundaries<\/strong><\/p>\n<ul>\n<li>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.<\/li>\n<\/ul>\n<h2>What to measure next<\/h2>\n<ol>\n<li><strong>Enable \u201cSelector Stats\u201d in the Performance panel<\/strong> (gear icon \u2192 Enable selector stats). Re-record the trace. This gives you, per Recalculate Style event, the top slow selectors and match counts \u2014 that tells you directly which CSS rules and how many elements are responsible.<\/li>\n<li><strong>Check the \u201cRecalculate Style\u201d event\u2019s initiator\/call stack<\/strong> in the trace to see what JS triggered it \u2014 a class toggle, a <code>style.setProperty<\/code>, an animation frame callback, etc.<\/li>\n<li><strong>Count how many elements are affected per recalc<\/strong> \u2014 DevTools shows \u201cElements Affected\u201d per Recalculate Style event in the summary pane. Compare that number to how many elements <em>actually<\/em> changed appearance \u2014 a big gap indicates over-broad invalidation.<\/li>\n<li><strong>Look at where in the DOM the triggering mutation happens<\/strong> \u2014 is it near the root (broad invalidation) vs. scoped to a small subtree (narrow, cheap)?<\/li>\n<li><strong>Check for forced synchronous style<\/strong> \u2014 look for \u201cForced reflow\u201d purple warnings; even though you said Layout is low, sometimes a forced <em>style<\/em> read (<code>getComputedStyle<\/code>) interleaved with a DOM write shows up as many small back-to-back Style events rather than one batched one.<\/li>\n<\/ol>\n<h2>Typical fixes once you find the culprit<\/h2>\n<ul>\n<li>Scope class\/state toggles to the smallest subtree possible instead of a common ancestor.<\/li>\n<li>Simplify selectors, prefer single class selectors over descendant chains.<\/li>\n<li>Move CSS custom property updates to the smallest scope needed.<\/li>\n<li>Batch DOM\/class changes so recalculation happens once, not per-mutation.<\/li>\n<li>Use <code>content-visibility: auto<\/code> or <code>contain: style layout<\/code> on independent subtrees to limit invalidation scope.<\/li>\n<\/ul>\n<\/blockquote>\n<\/details>\n<p>These days, given a slow-loading website, even as someone who\u2019s written about browser performance for years and who literally <em>worked on a browser performance team<\/em>, I would probably just chuck a Chrome trace at Claude Code and have it suggest improvements. In fact I\u2019ve done this very thing in my day job and gotten some good results.<\/p>\n<h2>The future of frontend<\/h2>\n<p>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.<\/p>\n<p>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:<\/p>\n<p><strong>The frontend is less risky to just hand to an agent.<\/strong> If you\u2019re 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\u2019ing it into production is (typically) much lower.<\/p>\n<p>Note I\u2019m <em>not<\/em> 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).<\/p>\n<p><strong>DevExp is becoming less critical overall.<\/strong> A lot of the pre-LLM discussion in the frontend space was about ergonomics versus outcomes: <a href=\"https:\/\/infrequently.org\/2018\/09\/the-developer-experience-bait-and-switch\/\">\u201cThe \u2018developer experience\u2019 bait-and-switch\u201d<\/a> 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.<\/p>\n<p>Meanwhile, <a href=\"https:\/\/x.com\/poteto\/status\/2089227731305464150\">Cursor<\/a> and <a href=\"https:\/\/www.viget.com\/articles\/using-ai-to-migrate-from-lit-to-react\">Viget<\/a> 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\u2019s case, and I suspect for Viget as well) is of course: \u201cthe agents know React.\u201d For better or worse, React is heavily overrepresented in the training weights, and \u201cagent experience\u201d is starting to matter more than developer experience.<\/p>\n<p><strong>Standards will catch up.<\/strong> I\u2019ve 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 \u2013 better CSS shorthands, terser JavaScript syntax, etc. \u2013 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\u2019s 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 <em>harder<\/em> because you have to coach the agent about things that aren\u2019t in its training weights.<\/p>\n<p>In some ways this shift might have already been underway. I remember several years ago at <a href=\"https:\/\/www.w3.org\/wiki\/TPAC\">TPAC<\/a>, 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\u2019t interested in that, because those APIs only affected the developer experience and didn\u2019t actually make the browser more capable (e.g. <a href=\"https:\/\/www.chromium.org\/teams\/web-capabilities-fugu\/\">Project Fugu<\/a>). That stuck with me because it\u2019s a good point: APIs like shadow DOM and custom elements don\u2019t 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.<\/p>\n<p>This doesn\u2019t mean that standards will disappear from the topics a frontend dev needs to keep up on, but I imagine it will become less about \u201cuse this newer syntax\u201d (an evergreen source of material for conference talks and articles) and more \u201chere are these emerging capabilities.\u201d 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\u2019s just a smaller pool of features to draw from.<\/p>\n<h2>Whither frontend education?<\/h2>\n<p>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.<\/p>\n<p>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 <a href=\"https:\/\/nolanlawson.com\/2022\/05\/21\/the-balance-has-shifted-away-from-spas\/\">SPAs are not the answer to everything<\/a>. 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\u2019t), but my guess is that since you\u2019re writing ~50% less code overall it won\u2019t matter.<\/p>\n<p>Second, making websites that work well for agents is probably going to be a fruitful endeavor for the near future. Vercel\u2019s <a href=\"https:\/\/is-agentic.com\/\">is-agentic<\/a> 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 \u201cAI\u201d on it is what gets people to care about it then hey, I\u2019m all for it.<\/p>\n<p>Note that I\u2019m a little bit less sanguine about this second point, because I\u2019m 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\u2019d much rather ask an agent than click through an infuriating series of buttons on a slow-loading website. The only reason I can\u2019t is because these websites explicitly block bots, or they don\u2019t offer an MCP, but I\u2019m sure there are several startups champing at the bit to solve that problem. So I\u2019m not sure how sustainable the current situation is.<\/p>\n<p>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 \u201cload-bearing.\u201d If those websites are slow, non-compliant, and riddled with security holes, then it may not be enough to ask the agent \u201cfix my website pls.\u201d There could be an opportunity here for real expertise, especially if there\u2019s money on the line and the vibe coder\u2019s knowledge of web development doesn\u2019t extend past \u201cwebsites are apps hosted on the internet.\u201d<\/p>\n<p>(I acknowledge that this is the shakiest of my three points, since I can totally imagine the next generation of \u201cself-healing\u201d web apps to eclipse the average expert in 2027 or 2028. But for the time being: yes, expertise still matters.)<\/p>\n<h2>Conclusion<\/h2>\n<p>The point of this post wasn\u2019t 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\u2019m a naturally gloomy person, and this post was me allowing myself to wallow in my own gloominess. I don\u2019t take any pleasure from noting that the huge body of knowledge I\u2019ve 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\u2019s not happening isn\u2019t a valid strategy either.<\/p>\n<p>There\u2019s a mood in some of the blogs I read these days along the lines of \u201cI\u2019m so tired of talking about AI\u201d or \u201cPlease don\u2019t mention AI to me ever again.\u201d I\u2019m 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\u2019s scary to admit that you don\u2019t know what\u2019s going to happen in a year. It\u2019s 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.<\/p>\n<p>The metaphor I\u2019ve been using is that an asteroid just hit the earth, and we\u2019re still surveying the wreckage. It\u2019s 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\u2019t recall thinking, \u201cUgh, I\u2019m so tired of talking about covid\u201d \u2013 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!).<\/p>\n<p>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\u2019m out of web standards, I don\u2019t 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.<\/p>\n<\/p><\/div>\n<p><a href=\"https:\/\/nolanlawson.com\/2026\/08\/23\/the-asteroid-currently-hitting-frontend-web-development\/?utm_source=tldrdev\">Source link <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":16,"featured_media":23742,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[143],"tags":[],"class_list":["post-23741","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"_links":{"self":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23741","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/comments?post=23741"}],"version-history":[{"count":0,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/posts\/23741\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media\/23742"}],"wp:attachment":[{"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/media?parent=23741"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/categories?post=23741"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/scannn.com\/lv\/wp-json\/wp\/v2\/tags?post=23741"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}