2Minutes: Event Loop In JavaScript
We’ve talked about the Call Stack running our synchronous code, and about Microtasks cutting in line before regular callbacks. But we never actually named the thing that ties all of it together and decides who goes next.
What is the Event Loop?
JavaScript has only one Call Stack. One thing runs at a time, always. So when you fire off a setTimeout or a fetch, JavaScript doesn’t wait around — it hands that work off to the browser (or Node) and moves on. The Event Loop is the process that’s constantly watching: “Is the Call Stack empty yet? Good. What’s next in line?”
Think of it like a single chef in a kitchen with two order tickets: a VIP ticket rail (Microtask Queue) and a regular ticket rail (Callback Queue). The chef always finishes the dish in hand, then clears every single VIP ticket before touching a regular one — even if a regular ticket arrived first.
console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("4");
// Output: 1, 4, 3, 21 and 4 run immediately — they’re synchronous, straight on the Call Stack. 3 beats 2 even though the setTimeout was scheduled first, because Promises go to the Microtask Queue, and the Event Loop always drains that VIP rail completely before it lets a single regular-ticket callback through.
The Trap: “0ms” Doesn’t Mean Now
This is why setTimeout(fn, 0) never actually runs at zero milliseconds. The Event Loop has to wait for the Call Stack to fully empty and the Microtask Queue to fully drain before it even looks at the Callback Queue. Your timer isn’t slow — it’s just waiting its turn in a line that Promises always get to skip.
The takeaway for today is: the Event Loop doesn’t execute your code, it just decides whose turn it is — Call Stack first, Microtasks always next, everything else after.
That’s 2Minutes Concept, see you in the next one!
Sources
https://alexweblab.com/articles/event-loop-macro-vs-microtasks