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.
De knop 'Vind ik leuk' reageert onmiddellijk, het hart vult zich, de teller loopt op – nog voordat de server ook maar heeft geantwoord. Dit is geen illusie van snelheid zoals in het artikel over micro-interacties, het gaat een stap verder: de interface toont een status die nog niet bestaat, en gaat ervan uit dat hij er zo aankomt. Ik zoek uit hoe je dit veilig bouwt – met een echte terugtrekking uit de leugen wanneer de aanname niet uitkomt – en waarom een handmatige setState plus catch een slechtere versie is van wat useOptimistic biedt.
CSS Houdini is niet één technologie, maar een verzameling specificaties in zeer uiteenlopende stadia van volwassenheid. Ontdek welk deel ervan vandaag productieklaar is, hoe `@property` en de paint worklet echt werken, en waarom de rest nog steeds experimenteel is.
Twee webshops, hetzelfde product, dezelfde serverresponstijd - toch voelt de ene sneller en betrouwbaarder aan dan de andere. Het verschil zit in micro-interacties: een paar honderd milliseconden animatie die bepalen of een gebruiker vertrouwt wat er op zijn scherm gebeurt. Ik ontleed ze vanaf de grondbeginselen - het trigger/feedback-model, wat er in de render-engine van de browser daadwerkelijk gebeurt, en prefers-reduced-motion.
