Zes kaarten op een dashboard, zes spinners, en ze verschijnen niet samen — ze verschijnen de één na de ander, als dominostenen, want elk begon pas te laden nadat het erboven klaar was. Dat is een waterval, en de totale wachttijd is niet het langzaamste verzoek, maar de som van alle. use() en Suspense breken de keten — maar het interessantste is de machinerie eronder: wat een gesuspend component werkelijk gooit, en hoe HTML die buiten volgorde aankomt toch op de juiste plek belandt.
Er is een reden waarom JavaScript-parallax er altijd lichtjes verkeerd uitziet — een beetje losstaand, alsof de lagen een halve frame achter de pagina zwemmen. Het is geen slordig code. Het is dat scroll-evenementen uw JavaScript bereiken nadat de browser het scrollen al heeft getekend. De browser heeft dit al eens opgelost, toen hij plakkerige headers in position: sticky omzette. Scroll-driven animations zijn dezelfde stap, tegelijk toegepast op alle scroll-gebonden effecten.
Tien jaar lang betekende het animeren van een miniatuur naar een hero-afbeelding één techniek: het element voor meten, erna meten, het verschil met een transform simuleren en afspelen. FLIP. Elke animatiebibliotheek doet het zo, en elke betaalt ervoor met JavaScript op de hoofdthread op het slechtst mogelijke moment. De View Transitions API verplaatst die hele truc naar de browser — en sinds React 19.2 en Next.js 16 bestaat het hele contract uit één prop genaamd name.
In het artikel over micro-interacties schreef ik dat transform en opacity animeren op de compositorthread, zodat zelfs een zware pagina de animatie van een knop niet hoeft te laten haperen. Dat klopt nog steeds – met één voorbehoud waar dat artikel over zweeg: als de hoofdthread geblokkeerd is door een lange JS-taak, krijgt de animatie misschien nooit de kans om te starten, omdat de klik-handler zelf in de wachtrij staat. INP is de metriek die precies dat gat meet – en scheduler.yield() is een van de weinige manieren om het echt te dichten.
Een lijst van duizend reacties rendert traag, dus grijp je naar react-window – en in ruil voor soepel scrollen verlies je Ctrl+F, het afdrukken van de pagina en gedeeltelijk de navigatie van schermlezers, omdat elementen buiten het venster fysiek ophouden te bestaan in de DOM. content-visibility lost hetzelfde probleem anders op: de elementen blijven in de DOM, de browser slaat alleen het kostbare layout- en paintwerk ervoor over totdat ze dicht bij het zichtbare gebied komen – en, verrassend genoeg, kan ze tijdelijk weer tonen zodra je er tekst in zoekt.
In het artikel over toegankelijkheid was een modal met display:none, die nog steeds in de accessibility-boom stond, een voorbeeld van een fout die ontstaat door een modal van nul op te bouwen met divs. De echte vraag is: waarom moest hij überhaupt van nul worden opgebouwd? Ik zoek uit wat de native <dialog> en het popover-attribuut gratis bieden – top layer, focus trap, light dismiss – en waar deze twee mechanismen zo sterk verschillen dat ze door elkaar halen zo naar een ontoegankelijke interface leidt.
