De asteroïde die momenteel inslaat op frontend webdevelopment

Ik heb nooit mijn brood verdiend met het praten over webdevelopment, maar ik heb deze blog en ik heb presentaties gegeven op conferenties en deelgenomen aan podcasts over zaken waar ik enthousiast over ben. Onlangs was mijn passie bijvoorbeeld het uitleggen van alle details van CSS-performance: hoe de Shadow DOM werkt, hoe de style-engine van de browser werkt, de valkuilen van CSS-in-JS, enzovoort.

Voor de grap besloot ik Claude Sonnet te vragen hoe het een Chrome-trace met hoge "Style Calculation"-kosten zou aanpakken. Dit is een van mijn favoriete hersenkrakers, omdat het het soort zaken is waar webdevelopers – zelfs ervaren ones! – keer op keer over struikelen. Claude gaf een bewonderenswaardig antwoord:

***

Prompt: Beantwoord zonder het internet te raadplegen: je kijkt naar een Chrome trace en je ziet herhaalde intervallen van hoge Style-kosten, maar relatief lage Layout-kosten. Naar welke zaken zoek je in de webapp om dit te optimaliseren? Wat meet je vervolgens?

Wat "Style"-kosten feitelijk betekenen

De Style (Recalculate Style) fase is waar de browser CSS-selectors matcht tegen de DOM en de uiteindelijke berekende stijl voor elk beïnvloed element vaststelt. Dit is kostbaar, ongeacht of er daadwerkelijk iets beweegt of van formaat verandert (dat is de taak van Layout). Als Style dus hoog is maar Layout laag, betaal je waarschijnlijk voor selector-matching/invalidatie over veel elementen, en niet voor complexe geometrie.

Waar je in de webapp naar moet zoeken

1. Selector-complexiteit en aantal

  • Overmatig complexe of diep geneste selectors (.a .b .c > .d + .e), vooral descendant combinators, dwingen de engine om per match-poging een groter deel van de DOM/ancestor-chain te doorlopen.
  • Universele selectors of attribuutselectors ([data-foo="bar"]) die breed worden toegepast.
  • CSS-in-JS bibliotheken die enorme aantallen unieke klassenamen/regels genereren (stijlherberekening moet de volledige regelset overwegen).

2. Invalidation scope — dit is meestal het grootste probleem

  • Een klasse/attribuut/stijl-toggle hoog in de DOM-boom (bijv. het wisselen van een klasse op <body> of een container op het hoogste niveau) kan een stijlherberekening forceren op grote subtrees, zelfs als de uiteindelijke stijlen van slechts enkele elementen veranderen.
  • Controleer of een enkele statuswijziging (bijv. een "theme"-klasse, een "loading"-klasse, een hover-status) veel meer elementen ongeldig maakt dan nodig is. "Selector Stats" in Chrome (inschakelen in DevTools Performance settings) laat zien welke selectors traag zijn en tegen hoeveel elementen ze zijn getest — dit is de meest nuttige volgende meting.

3. Frequentie/amplificatie

  • Iets dat de stijlherberekening vele malen per frame triggert — bijv. het lezen van een stijl/layout-eigenschap in een loop direct na een klassenwijziging (forceert synchrone herberekening), of een JS-animatie die .classList.toggle() of inline style-updates gebruikt op veel nodes per rAF tick in plaats van batching.
  • Herhaalde kleine DOM-mutaties die elk een style-pass forceren in plaats van gebundeld te worden in één pass.

4. Propagatie van overgeërfde/berekende eigenschappen

  • Het wijzigen van een overgeërfde eigenschap (zoals font-size of color op een gemeenschappelijke ancestor) dwingt een herberekening af van alle berekende stijlen van de afstammelingen, zelfs zonder layout-wijzigingen (bijv. color, visibility, cursor zijn Style-only en triggeren geen Layout).
  • Custom properties (CSS-variabelen) die worden gewijzigd op een hoog niveau — het updaten van een --custom-prop op :root of een gedeelde ancestor herberekent de stijl voor elk element dat hiernaar verwijst.

5. Shadow DOM / componentgrenzen

  • Bij gebruik van een framework met veel shadow roots of scoped styles: controleer of stijlherberekening onnodig wordt herhaald per component-instantie vanwege niet-gedeelde stylesheets.

Wat je vervolgens moet meten

  • Schakel "Selector Stats" in het Performance-paneel in (tandwiel-icoon → Enable selector stats). Neem de trace opnieuw op. Dit geeft je per Recalculate Style-event de traagste selectors en de match-counts, wat direct vertelt welke CSS-regels en hoeveel elementen verantwoordelijk zijn.
  • Controleer de initiator/call stack van het "Recalculate Style"-event in de trace om te zien welke JS dit triggerde — een klasse-toggle, een style.setProperty, een animation frame callback, etc.
  • Tel hoeveel elementen per herberekening worden beïnvloed — DevTools toont "Elements Affected" per Recalculate Style-event in het summary-paneel. Vergelijk dat getal met het aantal elementen dat daadwerkelijk van uiterlijk veranderde — een groot gat duidt op een te brede invalidatie.
  • Kijk waar in de DOM de triggerende mutatie plaatsvindt — is het nabij de root (brede invalidatie) of beperkt tot een kleine subtree (smalle, goedkope invalidatie)?
  • Controleer op geforceerde synchrone stijlen — zoek naar paarse "Forced reflow" waarschuwingen; zelfs als de Layout laag is, verschijnt een geforceerde stijl-read (getComputedStyle) afgewisseld met een DOM-write soms als veel kleine opeenvolgende Style-events in plaats van één gebundeld event.

Typische oplossingen zodra je de boosdoener hebt gevonden

  • Beperk klasse/status-toggles tot de kleinst mogelijke subtree in plaats van een gemeenschappelijke ancestor.
  • Vereenvoudig selectors; geef de voorkeur aan enkele klasse-selectors boven descendant chains.
  • Verplaats CSS custom property-updates naar de kleinst benodigde scope.
  • Bundel (batch) DOM/klasse-wijzigingen zodat herberekening één keer gebeurt, niet per mutatie.
  • Gebruik content-visibility: auto of contain: style layout op onafhankelijke subtrees om de invalidatie-scope te beperken.

***

Tegenwoordig zou ik, zelfs als iemand die jarenlang over browserperformance heeft geschreven en letterlijk in een browserperformance-team heeft gewerkt, bij een traag ladende website waarschijnlijk gewoon een Chrome-trace naar Claude Code gooien en suggesties voor verbeteringen vragen. Sterker nog, ik heb dit in mijn dagelijkse werk gedaan en goede resultaten behaald.

De toekomst van frontend

Waar laat dit de educatie in frontend-development? Niet in een goede positie, overduidelijk; ik wou dat ik hoopvoller antwoorden had voor mensen die (net als ik) veel voldoening haalden uit het proberen het niveau voor frontend-developers wereldwijd te verhogen. Ik heb echter wel wat vermoedens, en ik denk dat het probleem nog steeds de moeite waard is om over na te denken.

De kernvraag is waar frontend-development zelf in dit nieuwe tijdperk terechtkomt. Helaas voelt het voor mij alsof er verschillende trends zijn die wijzen tegen een verhoogde investering in frontend-kennis:

De frontend is minder risicovol om simpelweg aan een agent over te laten. Als je een agent gebruikt om een database-migratie te schrijven, wil je die waarschijnlijk door verschillende rondes van AI-codereview halen, hem zelf nauwgezet bestuderen, eerst op staging draaien, enzovoort. Maar als je met een agent een React-component schrijft, is het risico om dit zomaar in productie te "yolo-en" (meestal) veel lager.

Let op: ik zeg niet dat er nul risico's zijn; de agent kan de toegankelijkheid verpesten, een oneindige loop veroorzaken die gebruikers blokkeert, etc. Maar over het algemeen is frontend-code veel vluchtiger en vervangbaarder dan andere soorten code. Daarom verwacht ik dat veel AI-coders zich comfortabel zullen voelen om hun agent dit onbeheerd te laten afhandelen (voor beter of slechter).

DevExp (Developer Experience) wordt over het algemeen minder kritisch. Veel van de pre-LLM discussies in de frontend-ruimte gingen over ergonomie versus resultaten. Terwijl frameworks zoals Svelte en Solid al lang betogen dat hun ergonomie leidt tot betere resultaten dan React (minder code, betere performance, etc.), zien we dat bedrijven zoals Cursor en Viget hun codebases migreren van respectievelijk Solid en Lit naar React.

Omdat herschrijven minder duur is met agents, is dit misschien verrassend: waarom niet overstappen naar het performantere/minder verbose framework? Het antwoord is simpel: "de agents kennen React." Voor beter of slechter is React zwaar oververtegenwoordigd in de trainingsgewichten, en "agent experience" begint belangrijker te worden dan developer experience.

Standaarden zullen inhalen. Ik speculeer hier, maar ik stel me voor dat veel inspanningen om de ergonomie van het bouwen van websites te verbeteren – betere CSS shorthands, beknoptere JavaScript-syntax, etc. – als minder belangrijk worden beschouwd ten opzichte van zaken die echt impact hebben op performance en mogelijkheden. Uiteindelijk maakt het voor een agent niet veel uit of hij 3 regels CSS schrijft in plaats van 1, en het gebruik van nieuwere syntax kan zelfs lastiger zijn omdat je de agent moet coachen over zaken die niet in zijn trainingsgewichten zitten.

In zekere zin was deze verschuiving misschien al gaande. Jaren geleden vertelde iemand van het Chrome-team mij dat ze niet geïnteresseerd waren in web component-standaarden, omdat die API's alleen de developer experience beïnvloedden en de browser niet daadwerkelijk krachtiger maakten (zoals Project Fugu). Dat bleef bij me, want het is een goed punt: API's zoals Shadow DOM en custom elements geven webdevelopers geen nieuwe superkrachten; ze veranderen alleen waar en hoe de code wordt geschreven. Ik verwacht dat dergelijke zaken uit de spotlights zullen verdwijnen naarmate AI-coding het overneemt.

Dit betekent niet dat standaarden verdwijnen, maar het zal minder gaan over "gebruik deze nieuwere syntax" en meer over "hier zijn deze opkomende mogelijkheden."

Waar gaat frontend-educatie naartoe?

Hoe kan het veld van frontend-educatie zich aanpassen aan deze vijandige toekomst? Om niet geheel somber te eindigen, zijn hier enkele positieve richtingen:

Ten eerste moeten agents nog steeds worden onderwezen in het grote geheel. Agents en harnesses lijken dol te zijn op het schrijven van React en specifiek SPA's (Single Page Applications), maar SPA's zijn niet het antwoord op alles. Je kunt veel tokens verspillen aan een agent die een grote, complexe SPA schrijft voor je marketingwebsite, om vervolgens alle bugs met de terugknop, focus-status en performance op te lossen, of je kunt gewoon kiezen voor een MPA-framework (Multi-Page Application) zoals Astro of Eleventy.

Ten tweede zal het maken van websites die goed werken voor agents waarschijnlijk een vruchtbare onderneming zijn. Vercel's is-agentic is hier een goed voorbeeld van. Ironisch genoeg wijst dit terug naar goede fundamenten die publieke websites sowieso hadden moeten hebben: server-rendered content, proper accessibility, paginasnelheid, etc.

Ten derde kunnen we consultancy-diensten aanbieden voor "vibe-coded monstrositeiten". Er wordt momenteel een enorme hoeveelheid AI-gegenereerde frontend-code geproduceerd, en sommige daarvan zal zeker "load-bearing" worden. Als die websites traag zijn, niet compliant en riddled with security holes, is het misschien niet genoeg om de agent te vragen "fix mijn website pls." Hier ligt een kans voor echte expertise.

Conclusie

Het doel van dit bericht was niet om mezelf beter te voelen, of om te dansen op de graven van alle carrières die zijn omgegooid door de recente AI-boom. Ik ben van nature een somber persoon, en dit bericht was mijn manier om me in die somberheid over te geven. Ik haal geen plezier uit het constateren dat de enorme hoeveelheid kennis die ik in de loop der jaren heb opgebouwd bijna overbodig is geworden.

De metafoor die ik gebruik is dat er zojuist een asteroïde op de aarde is inslagen, en we zijn nog bezig de brokstukken te inventariseren. Het is moeilijk te voorspellen wat er gebeurt nadat het stof is neergedaald, maar de krater volledig negeren lijkt de ergste vorm van ontkenning.

Ik heb geen glazen bol, maar dit bericht was mijn poging om na te denken over waar mijn meest gekoesterde vakgebied in de toekomst naartoe gaat. Ik heb nog steeds veel liefde en respect voor het frontend-veld, en ik geef om wat er in de toekomst mee gebeurt. Het is wellicht onherkenbaar over een paar jaar, maar ik hoop dat mijn collega's een manier vinden om door al deze veranderingen te navigeren en te floreren in deze vreemde nieuwe wereld.