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ąć.
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.
Dwa sklepy, ten sam produkt, ten sam czas ładowania serwera – a jeden wydaje się szybszy i przyjemniejszy w obsłudze. Różnicę robią mikrointerakcje: kilkaset milisekund animacji, które decydują, czy użytkownik ufa temu, co widzi na ekranie. Rozkładam je na czynniki pierwsze – od modelu triggera i feedbacku, przez to, co naprawdę dzieje się w silniku przeglądarki, po prefers-reduced-motion.
CSS Houdini to nie jedna technologia, tylko zbiór specyfikacji w bardzo różnym stanie dojrzałości. Sprawdź, która jego część nadaje się dziś do produkcji, jak naprawdę działa @property i paint worklet, i dlaczego reszta wciąż jest eksperymentem.
