Det finns en anledning till att JavaScript-parallax alltid ser lite fel ut — lite frånkopplat, som om lagren simmar en halv frame bakom sidan. Det är inte slarvig kod. Det beror på att scroll-händelser når JavaScript efter att webbläsaren redan har ritat rullningen. Webbläsaren löste det här en gång, när den förvandlade klibbiga rubriker till position: sticky. Scroll-driven animations är samma drag, tillämpat på alla scroll-bundna effekter på en gång.
I tio år innebar animering av en miniatyrbild till en hero-bild en enda teknik: mät elementet före, mät efter, fejka skillnaden med en transform och spela upp. FLIP. Varje animationsbibliotek gör det, och varje betalar för det med JavaScript på huvudtråden vid det sämsta möjliga tillfället. View Transitions API flyttar hela tricket in i webbläsaren — och sedan React 19.2 och Next.js 16 består hela kontraktet av en enda prop kallad name.
I artikeln om mikrointeraktioner skrev jag att transform och opacity animeras på kompositeringstråden, så även en tung sida borde inte hacka en knappanimation. Det stämmer fortfarande – med ett förbehåll som den artikeln teg om: om huvudtråden är blockerad av en lång JS-uppgift kanske animationen aldrig får chansen att starta, eftersom själva klick-handlern väntar i kön. INP är måttet som mäter exakt den luckan – och scheduler.yield() är ett av få sätt att faktiskt stänga den.
'Gilla'-knappen reagerar direkt, hjärtat fylls i, räknaren ökar – innan servern ens har svarat. Det är inte samma hastighetsillusion som i artikeln om mikrointeraktioner, det är något som går längre: gränssnittet visar ett tillstånd som ännu inte finns, och antar att det strax kommer att göra det. Jag går igenom hur man bygger det säkert – med en verklig reträtt från lögnen när antagandet visar sig fel, och varför manuell setState plus catch är en sämre version av det useOptimistic ger.
Två butiker, samma produkt, samma svarstid från servern – ändå känns den ena snabbare och mer pålitlig. Skillnaden handlar om mikrointeraktioner: några hundra millisekunder animation som avgör om användaren litar på det som visas på skärmen. Jag bryter ner dem från grunden – trigger/feedback-modellen, vad som faktiskt händer i webbläsarens renderingsmotor, och prefers-reduced-motion.
CSS Houdini är inte en enda teknik, utan en samling specifikationer i mycket olika mognadsgrad. Ta reda på vilken del som duger för produktion idag, hur @property och paint worklet egentligen fungerar, och varför resten fortfarande är ett experiment.
