The JavaScript Event Loop: Asynchronicity on a Single Thread

Why it exists

JavaScript is single-threaded, meaning it can only execute one command at a time. If it had to wait for a slow network request to finish, the entire user interface would freeze. The event loop is the core mechanism that allows JavaScript to perform non-blocking asynchronous operations, keeping applications responsive.

The mental model

Think of the JavaScript runtime as a manager with three tools: a Call Stack (an inbox for the current task), Web APIs (specialist workers), and a Job Queue (a line of finished tasks waiting for approval). The manager works through the Call Stack. When an async task like setTimeout appears, it's handed off to a Web API specialist. The manager continues working on other tasks in the stack. Once the specialist is done, they place the result (a callback function) in the Job Queue. The Event Loop is the manager's rule: "As soon as my Call Stack is empty, I will take the first item from the Job Queue and start working on it."

How it works

The runtime consists of a Call Stack (LIFO), a Heap (for memory), and a Job Queue (FIFO). Synchronous code is pushed onto the Call Stack and executed immediately. When an asynchronous function is called, the host environment (like a browser) handles it via its own APIs, outside the main JavaScript thread. When the operation completes, the host places the associated callback function into the Job Queue. The event loop continuously checks: "Is the Call Stack empty?" If it is, it dequeues the first job from the queue and pushes it onto the stack for execution.

When to use it

You don't choose to "use" the event loop; it's the fundamental model that powers all asynchronous JavaScript. It's what makes async/await, Promises, setTimeout, and DOM event listeners (like onclick) work without freezing the browser. Understanding it is key to writing effective async code.

When not to use it

You cannot avoid the event loop, but you can break its rhythm. The main footgun is running long, synchronous, CPU-intensive code on the main thread. This is called "blocking the event loop" because while your code runs, the stack is never empty, and the loop cannot process UI updates or other async callbacks, making the page unresponsive. For heavy computation, use a Web Worker, which runs on a separate thread with its own stack and event loop.

One canonical example

Consider this code: console.log('First'); setTimeout(() => console.log('Second'), 0); console.log('Third');. The output is First, Third, Second. The setTimeout call is handed to the Web API, and its callback is placed in the Job Queue. The engine continues executing synchronous code, logging 'Third'. Only after the stack is empty does the event loop push the callback from the queue to the stack, which then logs 'Second'.