Kuusi korttia kojelaudalla, kuusi latausindikaattoria, ja ne eivät näy yhdessä — ne näkyvät yksi kerrallaan, kuin dominobrikettejä, koska jokainen kortti aloitti lataamisen vasta kun sen yläpuolinen oli valmis. Se on vesiputous, ja kokonaisvastausaika ei ole hitain pyyntö, vaan kaikkien summa. use() ja Suspense katkaisevat ketjun — mutta kiinnostavaa on alla oleva koneisto: mitä suspensoitunut komponentti oikeasti heittää, ja miten väärässä järjestyksessä saapuva HTML päätyy silti oikeaan paikkaan.
JavaScript-parallax näyttää aina hieman väärältä — hieman irralliselta, kuin kerrokset uisivat puoli ruutua sivun takana. Se ei ole huolimatonta koodia. Se johtuu siitä, että vieritystapahtumat saavuttavat JavaScriptin sen jälkeen kun selain on jo piirtänyt vierityksen. Selain ratkaisi tämän kerran, kun se muutti tarrautuvat otsikot position: sticky -ominaisuudeksi. Scroll-driven animations on sama veto, sovellettuna kaikkiin vieritykseen sidottuihin efekteihin kerralla.
Kymmenen vuotta kuvakkeen animointi hero-kuvaksi tarkoitti yhtä tekniikkaa: mittaa elementti ennen, mittaa jälkeen, väärentä ero transformilla ja toista. FLIP. Jokainen animaatiokirjasto tekee sen, ja jokainen maksaa siitä JavaScriptillä pääsäikeessä pahimmalla mahdollisella hetkellä. View Transitions API siirtää koko tempun selaimeen — ja React 19.2:n ja Next.js 16:n myötä koko sopimus koostuu yhdestä propista nimeltä name.
Mikrointeraktioita käsittelevässä artikkelissa kirjoitin, että transform ja opacity animoituvat kompositorisäikeellä, joten edes raskas sivu ei saisi nykiä painikkeen animaatiossa. Tämä pitää yhä paikkansa – yhdellä varauksella, josta tuo artikkeli vaikeni: jos pääsäie on tukossa pitkän JS-tehtävän vuoksi, animaatio ei ehkä koskaan saa tilaisuutta käynnistyä, koska itse klikkauskäsittelijä odottaa jonossa. INP on mittari, joka mittaa juuri tätä aukkoa – ja scheduler.yield() on yksi harvoista tavoista sulkea se todella.
Tuhannen kommentin lista renderöityy hitaasti, joten tartut react-windowiin – ja sulavan vierityksen vastineeksi menetät Ctrl+F:n, sivun tulostuksen ja osittain ruudunlukijan navigoinnin, koska ikkunan ulkopuoliset elementit lakkaavat fyysisesti olemasta DOM:ssa. content-visibility ratkaisee saman ongelman toisin: elementit pysyvät DOM:ssa, selain vain jättää niiden kohdalla väliin kalliin layout- ja piirtotyön, kunnes ne ovat lähellä näkyvää aluetta – ja, yllättäen, se osaa tilapäisesti paljastaa ne, kun etsit niistä tekstiä.
Saavutettavuusartikkelissa display:none-määrityksellä piilotettu modaali, joka oli silti olemassa saavutettavuuspuussa, oli esimerkki virheestä, joka syntyy, kun modaali rakennetaan tyhjästä diveillä. Todellinen kysymys kuuluu: miksi se piti ylipäätään rakentaa tyhjästä? Tarkastelen, mitä natiivi <dialog> ja popover-attribuutti antavat ilmaiseksi – top layerin, fokusloukun, light dismissin – ja missä nämä kaksi mekanismia eroavat toisistaan niin paljon, että niiden sekoittaminen on suora tie saavuttamattomaan käyttöliittymään.
