ست بطاقات على لوحة التحكم، ست مؤشرات تحميل، ولا تظهر معاً — تظهر واحدة تلو الأخرى كالدومينو، لأن كل بطاقة بدأت التحميل فقط بعد انتهاء التي فوقها. هذا هو الشلال، والوقت الإجمالي للانتظار ليس أبطأ طلب بل مجموع الكل. use() وSuspense يقطعان هذه السلسلة — لكن المثير للاهتمام هو الآلية الداخلية: ماذا يرمي المكوّن المُعلَّق فعلاً، وكيف يصل HTML الذي يصل بترتيب خاطئ إلى مكانه الصحيح.
هناك سبب يجعل التأثير المنظوري بـJavaScript يبدو دائماً غير صحيح قليلاً — منفصلاً بعض الشيء، كأن الطبقات تسبح نصف إطار خلف الصفحة. هذا ليس كوداً رديئاً. السبب هو أن أحداث التمرير تصل إلى JavaScript بعد أن يكون المتصفح قد رسم التمرير بالفعل. حلّ المتصفح هذا مرة واحدة، حين حوّل الترويسات اللاصقة إلى position: sticky. Scroll-driven animations هي نفس الخطوة، مطبّقة على جميع التأثيرات المرتبطة بالتمرير دفعة واحدة.
لعشر سنوات، كان تحريك الصور المصغّرة إلى صور البطل يعني تقنية واحدة: قِس العنصر قبل وبعد، وزيّف الفرق بـtransform، ثم اعرضه. FLIP. كل مكتبة حركات تفعل ذلك، وكل منها تدفع ثمنه بـJavaScript على الخيط الرئيسي في أسوأ لحظة ممكنة. View Transitions API ينقل الحيلة بأكملها إلى المتصفح — ومنذ React 19.2 وNext.js 16، يتكون العقد بأكمله من خاصية واحدة اسمها name.
كتبتُ في مقال التفاعلات الدقيقة أن transform وopacity تتحرّكان على خيط التركيب (compositor)، فحتى الصفحة الثقيلة لا ينبغي أن تُعطّل حركة الزر. هذا لا يزال صحيحًا – مع تحفّظ واحد سكت عنه ذلك المقال: إذا كان الخيط الرئيسي محجوزًا بمهمّة JS طويلة، فقد لا تحصل الحركة أبدًا على فرصة للبدء، لأنّ معالج النقرة نفسه ينتظر في الطابور. INP هو مقياس يقيس بالضبط هذه الفجوة – وscheduler.yield() إحدى الوسائل القليلة لسدّها فعليًّا.
قائمة من ألف تعليق تُعرَض ببطء، فتلجأ إلى react-window – وفي مقابل تمرير سلس تخسر Ctrl+F، وطباعة الصفحة، وجزءًا من تنقّل قارئ الشاشة، لأن العناصر خارج النافذة المرئية تتوقف عن الوجود فعليًا في DOM. تحلّ content-visibility المشكلة نفسها بطريقة مختلفة: تبقى العناصر في DOM، ويكتفي المتصفح بتجاهل العمل المكلف من تخطيط وطلاء لها، إلى أن تقترب من المنطقة المرئية – والمفاجئ أنها قادرة على كشفها مؤقتًا حين تبحث فيها عن نص.
في مقال إتاحة الوصول، كانت النافذة المنبثقة بخاصية display:none، التي بقيت مع ذلك موجودة في شجرة إتاحة الوصول، مثالًا على خطأ نتج عن بناء نافذة منبثقة من الصفر باستخدام عناصر div. السؤال الحقيقي هو: لماذا كان يجب بناؤها من الصفر أصلًا؟ أفحص ما يقدّمه عنصر <dialog> الأصيل وسمة popover مجّانًا – الطبقة العليا، وفخّ التركيز، والإغلاق الخفيف (light dismiss) – وأين يختلف هذان الآليتان بما يكفي لجعل الخلط بينهما طريقًا مباشرًا لواجهة غير قابلة للوصول.
