Seks kort på et dashbord, seks spinnere, og de vises ikke sammen — de vises én etter én, som dominobrikker, fordi hver enkelt bare begynte å laste etter at den ovenfor var ferdig. Det er et fossfall, og den totale ventetiden er ikke den tregeste forespørselen, men summen av alle. use() og Suspense bryter kjeden — men det interessante er maskineriet under: hva en suspendert komponent faktisk kaster, og hvordan HTML som ankommer i feil rekkefølge likevel lander på rett sted.
Det er en grunn til at JavaScript-parallaks alltid ser litt feil ut — litt frakoblet, som om lagene svømmer en halv frame bak siden. Det er ikke slurvete kode. Det er at scroll-hendelser når JavaScript etter at nettleseren allerede har tegnet rullingen. Nettleseren løste dette én gang tidligere, da den forvandlet klebrige overskrifter til position: sticky. Scroll-driven animations er det samme grepet, brukt på alle scroll-bundne effekter på én gang.
I ti år betød animasjon av et miniatyrbilde til et hero-bilde én teknikk: mål elementet før, mål etter, forfalsk forskjellen med en transform og spill av. FLIP. Hvert animasjonsbibliotek gjør det, og hvert betaler for det med JavaScript på hovedtråden på det verst mulige tidspunktet. View Transitions API flytter hele tricket inn i nettleseren — og siden React 19.2 og Next.js 16 er hele kontrakten én prop kalt name.
I artikkelen om mikrointeraksjoner skrev jeg at transform og opacity animeres på kompositeringstråden, så selv en tung side ikke burde få knappeanimasjonen til å hakke. Det stemmer fortsatt – med ett forbehold den artikkelen ikke nevnte: hvis hovedtråden er blokkert av en lang JS-oppgave, får animasjonen kanskje aldri sjansen til å starte, fordi selve klikk-handleren står og venter i køen. INP er metrikken som måler nøyaktig dette gapet – og scheduler.yield() er en av de få måtene å faktisk lukke det på.
En liste med tusen kommentarer rendrer sakte, så du griper til react-window – og i bytte mot jevn scrolling mister du Ctrl+F, utskrift av siden og delvis skjermleser-navigasjon, fordi elementene utenfor vinduet slutter å fysisk eksistere i DOM-en. content-visibility løser det samme problemet annerledes: elementene blir værende i DOM-en, nettleseren hopper rett og slett over det kostbare layout- og malingsarbeidet for dem helt til de kommer nær det synlige området – og, overraskende nok, kan den midlertidig avsløre dem når du søker etter tekst i dem.
I artikkelen om tilgjengelighet var en modal med display:none, som fortsatt fantes i tilgjengelighetstreet, et eksempel på en feil som følger av å bygge en modal fra bunnen med div-er. Det egentlige spørsmålet er: hvorfor måtte den i det hele tatt bygges fra bunnen? Jeg går gjennom hva den native <dialog> og popover-attributtet gir deg gratis – top layer, fokusfelle, light dismiss – og hvor disse to mekanismene skiller seg så mye at å forveksle dem er en enkel vei til et utilgjengelig grensesnitt.
