Sex kort på ett dashboard, sex spinnrar, och de visas inte tillsammans — de visas ett i taget, som dominobrickor, för varje kort startade bara laddningen efter det ovanför var klart. Det är ett vattenfall, och den totala väntetiden är inte den långsammaste förfrågan, utan summen av alla. use() och Suspense bryter kedjan — men det intressanta är maskineriet under: vad en suspenderad komponent faktiskt kastar, och hur HTML som anländer i fel ordning ändå hamnar på rätt ställe.
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.
En lista med tusen kommentarer renderas långsamt, så du griper efter react-window – och i utbyte mot smidig scrollning förlorar du Ctrl+F, sidutskrift och delvis skärmläsarnavigering, eftersom elementen utanför fönstret helt slutar existera i DOM. content-visibility löser samma problem på ett annat sätt: elementen finns kvar i DOM, webbläsaren hoppar bara över det kostsamma layout- och målningsarbetet för dem tills de hamnar nära det synliga området – och, förvånande nog, kan tillfälligt avslöja dem när du söker efter text i dem.
I artikeln om tillgänglighet var en modal med display:none, som ändå fanns kvar i tillgänglighetsträdet, ett exempel på ett fel som uppstod ur att bygga en modal från grunden med divar. Den verkliga frågan är: varför behövde den överhuvudtaget byggas från grunden? Jag går igenom vad den nativa <dialog> och attributet popover ger dig gratis – top layer, fokusfälla, light dismiss – och var de här två mekanismerna skiljer sig så pass mycket att man med lätthet bygger ett otillgängligt gränssnitt genom att blanda ihop dem.
