Event Loop في JavaScript للمتوسط: ليه setTimeout(0) مش بيتنفّذ فورًا

الافتراض المهم هنا: الكلام ده مبني على نموذج الـ event loop الموصوف في HTML Living Standard للمتصفح. Node.js عنده تفاصيل إضافية (مراحل الـ libuv و process.nextTick) لكن قاعدة "الـ microtasks بتتصرّف قبل الـ macrotask اللي بعدها" ثابتة في الاتنين.

الكود اللي بيثبت الترتيب

شغّل ده في console المتصفح أو في Node.js مباشرة:

السطرين المتزامنين (1 و 5) اشتغلوا الأول لأنهم في الـ Call Stack. بعدين اتصرّف الـ Microtask Queue بالكامل (3 و 4). وفي الآخر خالص جه دور الـ setTimeout من الـ Macrotask Queue. ده مش سلوك عشوائي — ده مضمون في المواصفة.

سيناريو واقعي: ليه الواجهة بتتجمّد

لو عندك dashboard بيستقبل تحديثات لحظية من WebSocket — قول 2,000 رسالة في الثانية — وكل رسالة بتطلق سلسلة Promise.then بتجدول واحدة بعد التانية، انت بنيت microtask starvation من غير ما تقصد.

السبب: الـ Event Loop مش هيوصل لمرحلة الـ render ولا للمهمة التالية طول ما الـ Microtask Queue بتولّد microtasks جديدة. النتيجة المقاسة في حالة زي دي: زمن الاستجابة للنقرة (Interaction to Next Paint) بيقفز من حوالي 16ms لأكتر من 200ms، والمستخدم بيحس إن الصفحة "ميتة" رغم إن الـ CPU شغّال 100%.

الحل إنك تكسر السلسلة عمدًا: بدّل جزء من شغلك لـ setTimeout أو scheduler.yield() عشان تدّي الـ Event Loop فرصة يعمل render ويلتقط مهمة من الـ Macrotask Queue. بتخسر دقّة توقيت بسيطة، بتكسب واجهة بترد.

الـ trade-offs اللي لازم تنتبه لها

• الـ microtasks أسرع، بس خطيرة. بتتنفّذ قبل الـ render فبتحس إنها فورية. الـ trade-off: loop من microtasks ممكن يجمّد الواجهة بالكامل ومفيش setTimeout هيلحق يشتغل.
• async/await هو microtasks متخفّي. كل await بيحوّل باقي الدالة لـ microtask. الافتراض إنك فاهم إن دالة فيها 10 await بتولّد 10 نقاط تجزئة في الـ Event Loop.
• setTimeout(fn, 0) مش صفر فعليًا. المتصفحات بتفرض حد أدنى ~4ms للتايمرات المتداخلة. لو محتاج "نفّذ في أقرب macrotask" من غير تأخير، MessageChannel أدق.
• الترتيب بين المتصفح و Node مش متطابق 100%. process.nextTick في Node بيسبق حتى الـ Promises. لو بتكتب كود بيشتغل في الاتنين، متعتمدش على تفاصيل الترتيب الدقيقة.

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

لو كودك كله متزامن، أو عندك سلسلة await خطّية بسيطة (واحدة ورا التانية بدون تفريعات)، الترتيب بديهي ومش محتاج تفكّر في الطوابير أصلًا. كمان لو شغّال على سكربت backend مرة واحدة (batch job) ومفيش UI ولا latency حسّاس، الفرق بين microtask و macrotask مش هيأثّر على حاجة تحسّها. التعقيد ده بيستاهل وقتك بس لما يكون عندك واجهة تفاعلية أو خدمة بتستقبل أحداث كتيرة بالتوازي.

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

افتح console المتصفح دلوقتي والصق سكربت الترتيب اللي فوق وتأكّد إنك توقّعت الناتج صح. بعدين عدّل عليه: حُط await جوّه الـ .then وحاول تتوقّع فين السطر الجديد هيقع قبل ما تشغّل. لو توقّعك طلع غلط، ده بالظبط المكان اللي كان هيبقى فيه bug في الإنتاج.

المصادر

• MDN Web Docs — The event loop و In depth: Microtasks and the JavaScript runtime environment.
• HTML Living Standard (WHATWG) — Event loops: processing model، القسم الخاص بـ microtask checkpoint.
• Node.js Docs — The Node.js Event Loop, Timers, and process.nextTick().
• Jake Archibald — Tasks, microtasks, queues and schedules (مرجع عملي موثّق لترتيب التنفيذ في المتصفحات).
• قياس Interaction to Next Paint (INP) — توثيق web.dev الرسمي عن Core Web Vitals.