יש סיבה שפרלקס JavaScript תמיד נראה קצת לא נכון — קצת מנותק, כאילו השכבות שוחות חצי פריים מאחורי הדף. זה לא קוד רשלני. זה בגלל שאירועי גלילה מגיעים ל-JavaScript אחרי שהדפדפן כבר ציייר את הגלילה. הדפדפן פתר את זה פעם אחת, כשהפך כותרות דביקות ל-position: sticky. Scroll-driven animations הוא אותה המהלך, מיושם על כל האפקטים הקשורים לגלילה בבת אחת.
עשר שנים, אנימציה של תמונה ממוזערת לתמונת הירו אמרה טכניקה אחת: מדוד לפני, מדוד אחרי, זייף את ההבדל עם transform ונגן. FLIP. כל ספריית אנימציות עושה זאת, וכל אחת משלמת על כך ב-JavaScript על ה-thread הראשי ברגע הגרוע ביותר האפשרי. View Transitions API מעביר את כל הטריק לדפדפן — ומאז React 19.2 ו-Next.js 16, כל החוזה מורכב מ-prop אחד בשם name.
במאמר על מיקרו-אינטראקציות כתבתי ש-transform ו-opacity מונפשים בתהליך הקומפוזיטור, כך שאפילו עמוד כבד לא אמור לגמגם באנימציית כפתור. זה עדיין נכון – עם הסתייגות אחת שהמאמר ההוא שתק לגביה: אם התהליך הראשי חסום על ידי משימת JS ארוכה, האנימציה עלולה לעולם לא לקבל הזדמנות להתחיל, כי ה-handler של הלחיצה עצמו ממתין בתור. INP היא המדד שמודד בדיוק את הפער הזה – ו-scheduler.yield() היא אחת הדרכים המעטות לסגור אותו באמת.
כפתור "לייק" מגיב מיד, הלב מתמלא, המונה עולה – עוד לפני שהשרת בכלל ענה. זו לא אשליית מהירות כמו במאמר על מיקרו-אינטראקציות, זה משהו רחוק יותר: הממשק מציג מצב שעדיין לא קיים, ומניח שהוא עומד להתקיים בעוד רגע. בודק איך בונים את זה בבטחה – עם נסיגה אמיתית מהשקר כשההנחה לא מתממשת, ולמה setState ידני עם catch הוא גרסה גרועה יותר של מה ש-useOptimistic נותן בחינם.
שתי חנויות, אותו מוצר, אותו זמן תגובה מהשרת – ובכל זאת אחת מהן מרגישה מהירה ואמינה יותר. ההבדל טמון במיקרו-אינטראקציות: כמה מאות מילישניות של אנימציה שמכריעות אם המשתמש בכלל סומך על מה שהוא רואה על המסך. אני מפרק אותן מהיסוד – מודל הטריגר/משוב, מה שבאמת קורה בתוך מנוע הרינדור של הדפדפן, ו-prefers-reduced-motion.
CSS Houdini הוא לא טכנולוגיה אחת, אלא אוסף מפרטים במצבי בשלות שונים מאוד. גלה איזה חלק ממנו מתאים היום לסביבת ייצור, איך `@property` ו-paint worklet באמת עובדים, ולמה שאר החלקים עדיין בגדר ניסוי.
