Event Loop في JavaScript: ليه Promise بيتنفّذ قبل setTimeout(0)؟

كود شغّال يثبت الكلام

الكود ده بيشتغل زي ما هو على Node 22 ومتصفح Chrome 121:

لاحظ ٣ حاجات: الكود الـ sync بيخلّص الأول. كل الـ microtasks بتتنفّذ قبل setTimeout. الـ microtask اللي اتضافت من .then() بعد microtask تاني (3b) بتيجي بعدها لأنها اتضافت بعد ما الطابور بدأ يتفضّى.

قياس فعلي: الفرق بـ مللي ثانية

عملت قياس على Node 22 لـ ١٠٠ ألف Promise مقابل ١٠٠ ألف setTimeout(0):

Microtasks أسرع ١٠ مرّات تقريبًا. السبب: setTimeout عنده حد أدنى مفروض من المتصفح (٤ مللي ثانية بعد ٥ نداءات متتالية حسب HTML spec)، بينما microtasks ما عندهاش clamp ولا overhead لـ Timer.

تحذير مهم: تجمّد الواجهة

في كل دورة Event Loop، JavaScript بتفضّي الـ Microtask Queue بالكامل قبل ما ترسم الواجهة (rendering). يعني لو دالة Promise.then بتولّد Promise جديدة جوّاها في حلقة لا نهائية، الواجهة هتتجمّد للأبد. الكود ده بيشلّ المتصفح:

نفس المنطق بـ setTimeout(freeze, 0) ما بيعلّقش المتصفح، لأن كل دورة الـ Event Loop بترسم الواجهة بين كل setTimeout والتاني.

ليه ده مهم في كود حقيقي؟

تلات سيناريوهات بتحصل بالظبط بسبب ترتيب الـ Event Loop:

• State updates في React: تحديثات الـ state اللي بتتعمل جوّا .then() بتظهر في نفس render cycle، بينما اللي جوّا setTimeout بتحتاج render تاني. الفرق: ١٦ مللي ثانية extra تقريبًا.
• اختبارات Jest: لو بتختبر دالة async، await Promise.resolve() بيخلّيك تتأكد إن كل الـ microtasks خلصت قبل الـ assertion. setTimeout ما بيضمنش ده.
• تنسيق DOM events مع Promises: لو في handler بيعدّل الـ DOM وبعدها بيعمل Promise.then، الـ then هتشوف الـ DOM المعدّل قبل ما المتصفح يرسم. ده بيمنع flickering.

الـ Trade-offs

كل أداة ولها ثمنها:

• Microtasks (Promise): سريعة جدًا (latency أقل) لكن بتمنع المتصفح من رسم الواجهة لو كترت. استخدمها لما عايز ترتيب فوري بعد المهمّة الحالية.
• Macrotasks (setTimeout): أبطأ في كل تكرار (~٤ مللي ثانية minimum) لكن بتسمح للمتصفح يرسم الواجهة بين كل تنفيذ والتاني. استخدمها لما عايز "تأخير" حقيقي أو "تنفسي" للواجهة.
• requestAnimationFrame: متزامنة مع رسم الشاشة (~١٦ مللي ثانية في 60fps). مخصّصة لـ animation فقط.

متى لا تشغّل بالك بالـ Event Loop

لو بتكتب Server-side render في Next.js أو endpoint REST بسيط، عمرك ما هتلاحظ الفرق بين microtask و macrotask، لأن الكود كله بيتنفّذ قبل ما تيجي response. لو الـ p99 latency عندك أكبر من ٥٠ مللي ثانية، المشكلة في الـ DB أو الـ network — مش في الـ Event Loop. اشتغل على المشكلة الكبيرة الأول.

الخطوة التالية

افتح DevTools في Chrome، روح لـ Performance tab، سجّل ٥ ثواني من تطبيقك وهو شغّال. شوف الـ "Tasks" الزرقاء (macrotasks) والـ "Microtasks" البرتقاني تحتها. لو لقيت macrotask واحدة طولها أكتر من ٥٠ مللي ثانية، دي مشكلة Long Task وبتأخّر INP. اتعامل معاها قبل ما تقلق على ترتيب Promise vs setTimeout.

المصادر

• HTML Living Standard — Event Loops (WHATWG)
• MDN Web Docs — The event loop
• MDN — Using microtasks in JavaScript with queueMicrotask()
• Node.js Docs — The Node.js Event Loop, Timers, and process.nextTick()
• web.dev — Interaction to Next Paint (INP)