The JavaScript Event Loop Explained Simply
SkillVeris Team
Engineering Team
The JavaScript event loop is the mechanism that lets a single-threaded language run asynchronous code by moving queued callbacks onto the call stack whenever it is empty.
In this guide, you'll learn:
- Synchronous code runs on the call stack; async operations are handed off to the browser or Node APIs, which queue a callback when they finish.
- The event loop continuously checks: if the stack is empty, it takes the next callback from a queue and runs it.
- Microtasks, such as resolved Promises, run before macrotasks like setTimeout callbacks, and the whole microtask queue drains between each macrotask.
- Long synchronous work blocks the loop and freezes the page, because callbacks cannot run until the stack clears.
1What Is the JavaScript Event Loop?
The JavaScript event loop is the coordination mechanism that allows single-threaded JavaScript to handle asynchronous tasks without blocking. JavaScript itself runs one piece of code at a time on a single call stack, but the event loop lets it kick off slow operations — timers, network requests, user events — and run their callbacks later, once the current work is done.
In short, the loop repeatedly asks one question: is the call stack empty? If it is, it takes the next waiting callback from a queue and pushes it onto the stack to run. That simple cycle is what makes JavaScript feel concurrent despite having only one thread.
2The Call Stack and Single Thread
Everything synchronous in JavaScript runs on the call stack, a last-in-first-out structure of function calls. When you call a function it is pushed on; when it returns it is popped off. Because there is only one stack and one thread, only one function executes at any instant.
This is why a long synchronous loop freezes the page: while it occupies the stack, nothing else — no clicks, no rendering, no timers — can run. The event loop cannot do its job until the stack is clear.
🔑One Thread, One Stack
JavaScript does exactly one thing at a time. Asynchronicity does not come from extra threads in your code — it comes from handing work to the environment and processing the results later via the event loop.
3Where Async Work Actually Happens
The asynchronous work itself does not run in your JavaScript thread. When you call setTimeout, fetch, or add an event listener, you hand the task to the host environment — the browser's Web APIs or Node's C++ APIs. Those run outside the single thread. When they finish, they do not interrupt your code; instead they place a callback into a queue for the event loop to pick up later.
- setTimeout: the timer is tracked by the environment, not your thread.
- fetch / XHR: the network request runs in the browser; its callback is queued on completion.
- DOM events: clicks and key presses queue their handlers when they fire.
- Node I/O: file and socket operations run in libuv's thread pool, then queue callbacks.
4Microtasks vs Macrotasks
There is not one queue but two priority levels, and knowing the difference explains most confusing async ordering. Macrotasks include setTimeout, setInterval, and I/O callbacks. Microtasks include resolved Promise callbacks and queueMicrotask. After each macrotask, the event loop drains the entire microtask queue before rendering or running the next macrotask.
- Macrotasks: setTimeout, setInterval, setImmediate (Node), I/O, UI events.
- Microtasks: Promise .then/.catch/.finally, queueMicrotask, async/await continuations.
- Order rule: run one macrotask, then drain ALL microtasks, then repeat.
- Consequence: a resolved Promise callback runs before a setTimeout(fn, 0) queued earlier.
A Telling Example
The output of this snippet surprises many developers. The synchronous logs print first, then the microtask (Promise), then the macrotask (setTimeout) — regardless of the zero delay.
console.log('1');
setTimeout(() => console.log('2'), 0); // macrotask
Promise.resolve().then(() => console.log('3')); // microtask
console.log('4');
// Output order: 1, 4, 3, 25Why setTimeout Zero Is Not Immediate
setTimeout(fn, 0) does not run fn immediately. It schedules fn as a macrotask that can only run after the current synchronous code finishes and the call stack empties. The zero is a minimum delay, not a guarantee — the callback waits its turn in the queue behind everything already running.
This is a favourite interview question precisely because it exposes whether you understand the loop. The delay is not about time; it is about queue position.
💡Yielding to the Loop
setTimeout(fn, 0) is a handy way to defer work until after the current stack clears — for example, to let the browser paint before running a heavy follow-up task.
6How Blocking Freezes the Page
Because the event loop only advances when the stack is empty, any long-running synchronous code blocks everything. A heavy computation, a giant synchronous loop, or a huge JSON.parse will stop clicks from registering and animations from updating until it completes. The fix is to break the work up, defer it with setTimeout, or offload it to a Web Worker that runs on a separate thread.
- Symptom: the UI freezes, buttons do not respond, animations stutter.
- Cause: synchronous code monopolises the single thread and stalls the loop.
- Fixes: chunk the work, yield with setTimeout, or use a Web Worker.
- Web Workers: run genuinely parallel code off the main thread for heavy computation.
7Common Mistakes to Avoid
Most event-loop confusion comes from expecting async callbacks to run immediately or in a different order than the queue rules dictate.
- Expecting setTimeout(fn, 0) to run before the rest of the current synchronous code.
- Assuming a Promise .then runs after a setTimeout scheduled earlier — microtasks win.
- Running heavy CPU work on the main thread and blaming the framework for a frozen UI.
- Believing async code uses extra threads in your JavaScript — the environment does the waiting.
- Creating an infinite chain of microtasks, which starves macrotasks and rendering entirely.
⚠️Microtask Starvation
A microtask that keeps queuing more microtasks never lets the loop reach rendering or timers. The page appears hung even though your code is technically running.
8Key Takeaways
The event loop becomes intuitive once you hold these points in mind.
- JavaScript is single-threaded; the event loop schedules async callbacks when the stack is empty.
- Async work runs in the environment (Web APIs / Node), which queues callbacks on completion.
- Microtasks (Promises) run before macrotasks (setTimeout), draining fully between macrotasks.
- setTimeout(fn, 0) defers to after the current stack clears — it is never truly immediate.
- Long synchronous work blocks the loop; chunk it or move it to a Web Worker.
9Frequently Asked Questions
Q: Is JavaScript single-threaded or multi-threaded? A: The JavaScript execution model is single-threaded — one call stack runs one thing at a time. Asynchronous behaviour comes from the host environment, which handles timers and I/O outside that thread and queues callbacks for the event loop. Web Workers can add real parallel threads, but they run separate scripts.
Q: What is the difference between microtasks and macrotasks? A: Microtasks (resolved Promises, queueMicrotask, async continuations) have higher priority and the entire microtask queue drains after each macrotask. Macrotasks (setTimeout, setInterval, I/O, UI events) run one at a time, with all microtasks flushed in between. This is why a Promise callback runs before a setTimeout scheduled at the same moment.
Q: Why does setTimeout with 0 milliseconds not run instantly? A: Because it schedules the callback as a macrotask that can only execute once the current synchronous code finishes and the call stack is empty. The zero is a minimum delay and a queue position, not an immediate execution.
Q: What causes a webpage to freeze? A: Long-running synchronous JavaScript on the main thread blocks the event loop, so clicks, rendering, and timers cannot run until it completes. Break heavy work into chunks, defer parts with setTimeout, or move computation into a Web Worker to keep the interface responsive.
Related Reading
Get The Print Version
Download a PDF of this article for offline reading.
About the Publisher
SkillVeris Team
Engineering Team
Our engineering writers turn abstract code concepts into hands-on, project-driven learning experiences.
View all postsRelated Posts
Never miss an update
Get the latest tutorials and guides delivered to your inbox.
No spam. Unsubscribe anytime.