Event Loop in JavaScript

function multiply(a, b) {
  return a * b;
}

function square(n) {
  return multiply(n, n);
}

function printSquare(n) {
  const result = square(n);
  console.log(result);
}

printSquare(4);

Call Stack Flow for printSquare(4):

1. printSquare(4) is pushed onto the Call Stack.
2. square(4) is pushed onto the Call Stack.
3. multiply(4, 4) is pushed onto the Call Stack.
4. multiply returns 16, pops off the Call Stack.
5. square returns 16, pops off the Call Stack.
6. console.log(16) is pushed onto the Call Stack.
7. console.log finishes, pops off the Call Stack.
8. printSquare finishes, pops off the Call Stack.

If a function takes too long to execute on the Call Stack, it blocks everything else, leading to a

frozen user interface. This is often referred to as a "blocking" operation.

2. Web APIs (or Browser APIs / Node.js APIs)

When JavaScript encounters asynchronous operations (like setTimeout, fetch requests, DOM events like click), it doesn't handle them directly in the Call Stack. Instead, it hands them off to Web APIs (if running in a browser environment) or Node.js APIs (if running in a Node.js environment). These APIs are part of the browser or Node.js runtime, not the JavaScript engine itself.

Real-world Example: Imagine the Call Stack is a busy chef in a kitchen. When an order comes in for a dish that takes a long time to cook (like baking a cake), the chef doesn't stand there waiting. Instead, they hand the cake order to an oven (Web API) and immediately go back to preparing other, quicker dishes. The oven works in the background.

Common Web APIs include:

• setTimeout() and setInterval() (for timers)
• fetch() (for network requests)
• DOM events (click, mouseover, keydown, etc.)
• XMLHttpRequest

When a Web API finishes its task (e.g., a setTimeout timer expires, a fetch request receives a response, a click event occurs), it doesn't immediately put its callback function back onto the Call Stack. Instead, it places the callback into a queue.

3. The Callback Queue (or Task Queue / Message Queue)

The Callback Queue is where asynchronous operations send their callback functions once they are completed by the Web APIs. These callbacks wait patiently in line, in the order they were completed.

Real-world Example: Continuing our kitchen analogy, once the oven finishes baking the cake, it doesn't interrupt the chef. Instead, it places a

note (the callback) on a counter (the Callback Queue) for the chef to pick up when they are free.

4. The Event Loop

This is the heart of JavaScript's asynchronous nature. The Event Loop is a constantly running process that performs one simple but crucial job: it continuously checks if the Call Stack is empty. If the Call Stack is empty, it then looks at the Callback Queue. If there are any callbacks in the Callback Queue, it takes the first one and pushes it onto the Call Stack for execution.

Real-world Example: Our chef (Call Stack) is busy cooking. The oven (Web API) finishes the cake and puts a note on the counter (Callback Queue). The Event Loop is like a diligent kitchen assistant who constantly peeks at the chef. The moment the chef finishes their current task (Call Stack is empty), the assistant immediately grabs the next note from the counter (Callback Queue) and hands it to the chef. This way, the chef is always busy, but never blocked by waiting for the oven.

The Cycle:

1. Synchronous code runs on the Call Stack.
2. When an asynchronous operation is encountered, it's handed off to a Web API.
3. The Web API performs its task in the background.
4. Once the Web API's task is complete, its associated callback function is moved to the Callback Queue.
5. The Event Loop continuously monitors the Call Stack and the Callback Queue.
6. If the Call Stack is empty, the Event Loop takes the first callback from the Callback Queue and pushes it onto the Call Stack.
7. The callback then executes on the Call Stack.

This continuous cycle allows JavaScript to handle long-running operations without blocking the main thread, ensuring a smooth and responsive user experience.

Microtask Queue (Promises and async/await)

In addition to the regular Callback Queue (also known as the Task Queue or Macrotask Queue), there's another queue called the Microtask Queue. This queue has higher priority than the Callback Queue. Callbacks from Promises (.then(), .catch(), .finally()) and async/await functions are placed in the Microtask Queue.

The Event Loop checks the Microtask Queue before checking the Callback Queue. This means all pending microtasks will be executed before any macrotasks (from the Callback Queue) are processed in a given loop iteration.

Expected Output:

Explanation:

1. console.log("1. Start") executes immediately on the Call Stack.
2. setTimeout is handed to the Web API. Its callback goes to the Callback Queue after 0ms.
3. Promise.resolve().then() immediately resolves. Its callback goes to the Microtask Queue.
4. console.log("4. End") executes immediately on the Call Stack.
5. The Call Stack is now empty. The Event Loop checks the Microtask Queue first. It finds and pushes the Promise callback to the Call Stack.
6. console.log("3. Promise microtask") executes.
7. The Call Stack is empty again. The Event Loop checks the Microtask Queue (it's empty now) and then the Callback Queue. It finds and pushes the setTimeout callback to the Call Stack.
8. console.log("2. setTimeout callback") executes.

Conclusion

The JavaScript Event Loop is a sophisticated yet elegant system that allows JavaScript, despite its single-threaded nature, to handle complex asynchronous operations efficiently. By understanding the interplay between the Call Stack, Web APIs, the Callback Queue, and the Microtask Queue, developers can write non-blocking, responsive, and high-performance JavaScript applications. Mastering the Event Loop is key to truly understanding how JavaScript works under the hood and is essential for debugging and optimizing asynchronous code.

live