Sześć kart na dashboardzie, sześć spinnerów, i nie pojawiają się razem – pojawiają się jeden po drugim, jak kostki domina, bo każdy zaczął pobierać dane dopiero wtedy, gdy skończył ten nad nim. To waterfall, a łączne czekanie to nie najwolniejsze zapytanie, tylko suma wszystkich. use() i Suspense rozrywają ten łańcuch, ale najciekawsza jest maszyneria pod spodem: co naprawdę rzuca zawieszony komponent i jak HTML docierający nie po kolei trafia mimo to we właściwe miejsce.
Jest powód, dla którego parallax w JavaScripcie zawsze wygląda odrobinę nie tak – lekko odklejony, jakby warstwy pływały pół klatki za stroną. To nie niechlujny kod. To fakt, że zdarzenia scrolla docierają do twojego JavaScriptu już po tym, jak przeglądarka narysowała przewinięcie. Przeglądarka rozwiązała to już raz, zamieniając przyklejone nagłówki w position: sticky. Scroll-driven animations to ten sam ruch, zastosowany od razu do wszystkich efektów powiązanych ze scrollem.
Przez dziesięć lat animowanie miniatury w duży obraz oznaczało jedną technikę: zmierz element przed, zmierz po, udawaj różnicę transformem i puść. FLIP. Robi to każda biblioteka animacji i każda płaci za to JavaScriptem na głównym wątku w najgorszym możliwym momencie. View Transitions API przenosi całą tę sztuczkę do przeglądarki – a od Reacta 19.2 i Next.js 16 całym kontraktem jest jeden prop o nazwie name.
W artykule o mikrointerakcjach pisałem, że transform i opacity animują się na wątku kompozytora, więc nawet ciężka strona nie powinna zacinać animacji przycisku. To wciąż prawda – z jednym zastrzeżeniem, o którym tamten artykuł milczał: jeśli główny wątek jest zablokowany długim zadaniem JS, animacja może nigdy nie dostać szansy wystartować, bo sam handler kliknięcia czeka w kolejce. INP to metryka, która mierzy dokładnie tę lukę – i scheduler.yield() to jeden z niewielu sposobów, żeby ją realnie zamknąć.
Lista tysiąca komentarzy renderuje się wolno, więc sięgasz po react-window – i w zamian za płynny scroll tracisz Ctrl+F, drukowanie strony i częściowo nawigację czytnika ekranu, bo elementy poza oknem przestają fizycznie istnieć w DOM. content-visibility rozwiązuje ten sam problem inaczej: elementy zostają w DOM, przeglądarka po prostu pomija dla nich kosztowną pracę layoutu i malowania, dopóki nie znajdą się blisko widocznego obszaru – i, co zaskakujące, potrafi je tymczasowo odsłonić, gdy szukasz w nich tekstu.
W artykule o dostępności modal z display:none, który dalej istniał w drzewie dostępności, był przykładem błędu wynikającego z budowania modala od zera na divach. Prawdziwe pytanie brzmi: dlaczego w ogóle trzeba było go budować od zera? Sprawdzam, co daje za darmo natywny <dialog> i atrybut popover – top layer, pułapkę fokusu, light dismiss – i gdzie te dwa mechanizmy się różnią na tyle, że pomylenie ich to prosta droga do niedostępnego interfejsu.
