Asynchronous JavaScript & The EVENT LOOP — From Scratch

---

Note: The Call Stack will execute any execution context that enters it — no exceptions.
TL;DR: The Call Stack has no timer — it just runs what's inside it, line by line.

---

Understanding JavaScript in the Browser

JavaScript, by design, is single-threaded and synchronous. But wait — if it's synchronous, how does it handle things like network requests, timers, or user interactions without blocking the browser?

Here’s the secret: JavaScript alone can’t do it all. It relies on the browser environment to handle tasks that would otherwise require multithreading or system-level capabilities.

What Powers the JavaScript Runtime?

When you run JavaScript in the browser, it works hand-in-hand with:

• The JavaScript Engine (e.g., V8 in Chrome)

• The Call Stack

• The Web APIs (provided by the browser)

• The Callback Queue

• The Microtask Queue

• And the Event Loop (the orchestrator)

---

🔌 Web APIs: The Superpowers from the Browser

Web APIs are not part of JavaScript. They’re features provided by the browser — available to JavaScript via the global window object. Examples include:

• setTimeout() – scheduling tasks

• fetch() – making HTTP requests

• document – interacting with the DOM

• console.log() – printing to the dev console

• localStorage – storing data in the browser

While we often use these without the window. prefix (like setTimeout()), behind the scenes they are accessed as window.setTimeout().

---

🛠️ A Simple Asynchronous Code Example

Let’s take a look at a basic async operation:

console.log("Start");

setTimeout(function cb() {
  console.log("Timer expired");
}, 5000);

console.log("End");

What Happens Here?

1. A Global Execution Context (GEC) is created and pushed to the Call Stack.

2. console.log("Start") is executed → “Start” is printed.

3. setTimeout(cb, 5000) is encountered:

   • The setTimeout Web API is triggered.

   • The callback cb() is registered, and a 5-second timer starts.

4. console.log("End") is executed → “End” is printed.

5. After 5 seconds, the timer expires — but the callback cb() cannot go straight to the Call Stack.

6. Instead, it goes to the Callback Queue.

7. The Event Loop checks if the Call Stack is empty.

8. Once the Call Stack is clear, it pushes cb() into it and executes → “Timer expired” is printed.

---

🔄 Event Loop & Callback Queue Explained

The Event Loop is the invisible mechanism that ensures JavaScript remains non-blocking.

• It constantly monitors the Call Stack and Callback Queue.

• If the Call Stack is empty and there’s something in the Callback Queue, it pushes it onto the Call Stack.

• This is how asynchronous code is eventually executed.

Why Do We Need a Callback Queue?

Imagine a button clicked six times rapidly:

document.getElementById("btn").addEventListener("click", function cb() {
  console.log("Button clicked");
});

Each click triggers the callback cb():

• These callbacks are stored in the Callback Queue.

• The Event Loop pushes them one by one into the Call Stack when it's free.

• This queuing mechanism avoids chaos and maintains the execution order.

---

🧬 Promises & The Microtask Queue

Here’s where it gets interesting. Let’s consider this:

console.log("Start");

setTimeout(function cbT() {
  console.log("Timeout callback");
}, 5000);

fetch("https://api.example.com").then(function cbF() {
  console.log("Fetch callback");
});

console.log("End");

Step-by-Step Breakdown:

1. “Start” is logged.

2. setTimeout() registers cbT() with a 5-second delay.

3. fetch() initiates a network request and registers cbF() to be executed once the response arrives (say in 2 seconds).

4. “End” is logged.

5. After 2 seconds, cbF() enters the Microtask Queue.

6. After 5 seconds, cbT() enters the Callback Queue.

7. The Event Loop gives priority to the Microtask Queue:

   • It empties the Microtask Queue first → cbF() is executed.

   • Then it processes the Callback Queue → cbT() is executed.

Output:

Start  
End  
Fetch callback  
Timeout callback

---

⚖️ Microtask Queue vs Callback Queue

Starvation occurs if the Microtask Queue keeps adding new tasks recursively. This can delay or completely block the Callback Queue from being processed.

---

Common Interview Questions

1. What is the Event Loop in JavaScript?

The Event Loop continuously checks the Call Stack and Callback/Microtask Queues. If the Call Stack is empty, it pushes the next queued task (prioritizing Microtask Queue) onto the Call Stack.

---

2. What’s the difference between Microtask Queue and Callback Queue?

Microtasks (like Promise.then) are processed before tasks in the Callback Queue (setTimeout, DOM events). Microtasks have higher priority.

---

3. Is console.log() part of JavaScript?

No. It’s part of the browser’s console Web API, accessed via the window object.

---

4. What happens if setTimeout is set to 0ms?

Even with 0ms, the callback is queued and must wait for the Call Stack to be clear. So, it's never truly "immediate".

---

5. Why do event listeners stay in memory after code execution?

Event listeners are registered in the Web API environment. They stay alive to respond to events unless manually removed or the page is unloaded. This is why you should remove listeners when they’re no longer needed to avoid memory leaks.

---

6. Are synchronous callbacks also handled by the Web API environment?

No. Only asynchronous callbacks (like from setTimeout, fetch, etc.) are registered with Web APIs. Synchronous callbacks used with methods like map, filter, or reduce are handled directly by the JavaScript engine.

---

✅ Final Thoughts

JavaScript may be single-threaded, but with the help of the browser’s Web APIs, Callback and Microtask Queues, and the mighty Event Loop — it becomes incredibly powerful and responsive.

Mastering this internal flow will transform your debugging skills, optimize your performance logic, and give you a major edge in interviews.

Stay curious. Debug deeply. Learn beyond the syntax. 🚀

---

Best Video to learn this topic :