Seks kort på et dashboard, seks spinnere, og de vises ikke sammen — de vises én efter én, som dominobrikker, fordi hvert kort kun begyndte at indlæse efter det ovenfor var færdigt. Det er et vandfald, og den samlede ventetid er ikke den langsomste forespørgsel, men summen af alle. use() og Suspense bryder kæden — men det interessante er maskineriet underneden: hvad en suspenderet komponent faktisk kaster, og hvordan HTML der ankommer i forkert rækkefølge alligevel lander det rigtige sted.
Der er en grund til at JavaScript-parallax altid ser lidt forkert ud — lidt frakoblet, som om lagene svømmer en halv frame bag siden. Det er ikke sjusket kode. Det skyldes at scroll-hændelser når JavaScript efter browseren allerede har tegnet rulningen. Browseren løste dette én gang, da den forvandlede klæbrige overskrifter til position: sticky. Scroll-driven animations er det samme træk, anvendt på alle scroll-bundne effekter på én gang.
I ti år betød animering af et miniaturebillede til et hero-billede én teknik: mål elementet før, mål efter, forfalsk forskellen med en transform og afspil. FLIP. Hvert animationsbibliotek gør det, og hvert betaler for det med JavaScript på hovedtråden på det værst mulige tidspunkt. View Transitions API flytter hele tricket ind i browseren — og siden React 19.2 og Next.js 16 består hele kontrakten af én prop kaldet name.
I artiklen om mikrointeraktioner skrev jeg, at transform og opacity animeres på kompositørens tråd, så selv en tung side ikke burde få en knapanimation til at hakke. Det er stadig sandt – med ét forbehold, som den artikel ikke nævnte: hvis hovedtråden er blokeret af en lang JS-opgave, får animationen måske aldrig chancen for at starte, fordi selve klik-handleren venter i kø. INP er den metrik, der måler præcis dette hul – og scheduler.yield() er en af de få måder, man reelt kan lukke det på.
En liste med tusind kommentarer renderer langsomt, så du griber til react-window – og til gengæld for en flydende scroll mister du Ctrl+F, sideudskrift og delvist skærmlæserens navigation, fordi elementer uden for vinduet holder op med at eksistere fysisk i DOM'en. content-visibility løser det samme problem på en anden måde: elementerne bliver i DOM'en, browseren springer bare det dyre layout- og maling-arbejde over for dem, indtil de kommer tæt på det synlige område – og kan overraskende nok midlertidigt afsløre dem, når du søger efter tekst i dem.
I artiklen om tilgængelighed var en modal med display:none, som stadig fandtes i tilgængelighedstræet, et eksempel på en fejl, der opstod ved at bygge en modal fra bunden med divs. Det reelle spørgsmål er: hvorfor skulle den overhovedet bygges fra bunden? Jeg undersøger, hvad det native <dialog>-element og popover-attributten giver dig gratis – top layer, fokusfælde, light dismiss – og hvor de to mekanismer adskiller sig så meget, at det er let at forveksle dem og ende med en utilgængelig grænseflade.
