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.
Przycisk „Polub” reaguje natychmiast, serce się wypełnia, licznik rośnie – zanim serwer w ogóle odpowiedział. To nie iluzja szybkości z artykułu o mikrointerakcjach, to coś dalej idącego: interfejs pokazuje stan, który jeszcze nie istnieje, i zakłada, że zaraz zaistnieje. Sprawdzam, jak zbudować to bezpiecznie – z realnym wycofaniem się z kłamstwa, gdy założenie się nie sprawdzi, i dlaczego ręczny setState plus catch to gorsza wersja tego, co daje useOptimistic.
„use server” wygląda jak składniowy cukier na fetch do API route – i właśnie dlatego większość wdrożeń traktuje go jak zwykłe wywołanie funkcji. To błąd o konkretnych konsekwencjach: każda funkcja oznaczona „use server” staje się publicznym punktem końcowym w sieci, a formularz zbudowany na tym mechanizmie działa nawet zanim JavaScript zdąży się załadować. Sprawdzam, co faktycznie dzieje się pod tą dyrektywą, i gdzie leżą pułapki, których nie widać w dokumentacji na pierwszy rzut oka.
Poprawny HTML to dopiero początek. Sprawdź, jak naprawdę działa accessibility tree, dlaczego ARIA częściej szkodzi niż pomaga, i zbuduj razem ze mną dostępny akordeon, live region oraz obsługę fokusu w Next.js.
