It’s one of the first things you learn about JavaScript: it’s a single-threaded language. Yet, we use it to build complex applications that handle user input, fetch data over the network, and run timers simultaneously, all without freezing up.

This seems like a paradox. How can a single worker handle multiple jobs at once?
The answer is that the JavaScript engine doesn’t work alone. It’s part of a bigger team, and understanding that teamwork is the key to unlocking how JavaScript handles asynchronicity.

I recently wrote on how javascript handles Promises, where I discussed about asyncronus programming in Javascript. So thought of writting an in-depth about Asyncronus programming.

The Single Thread (Javscript Engine)

First, let’s be clear about what “single-threaded” means. At the heart of JavaScript is the engine (like V8 in Chrome and Node.js). This engine has one Call Stack.
The Call Stack is a “Last-In, First-Out” data structure. When you call a function, it’s pushed onto the stack. When that function finishes, it’s popped off. The engine executes whatever is at the top of the stack. That’s it. It can only ever process one function at a time.

function first() {
  console.log('First');
}
function second() {
  first();
  console.log('Second');
}
second();

In this code, second() is pushed to the stack. Then second() calls first(), so first() is pushed on top. first() runs and is popped off. Then second() continues, runs its console.log, and is popped off. This is the simple, synchronous, one-track mind of JavaScript.

If we ran a slow network request on this single stack, it would block everything else. The browser would freeze. Clicks wouldn’t work. This is called blocking the main thread, and it’s where the rest of the team comes in.

The Team (The Runtime Environment)

The JavaScript engine doesn’t run in a vacuum. It runs inside a host environment, like a web browser or a Node.js server. These environments provide capabilities far beyond what the JS engine itself can do.

These environments provide a separate set of threads for long-running operations. They expose these to JavaScript through a set of APIs. In the browser, these are called Web APIs.

When you call an asynchronous function like setTimeout, fetch, or add a DOM event listener, you're not telling the JavaScript engine to pause and wait. You're telling the host environment:

Hey, Browser! Can you handle this for me? Start this timer / make this network request. When you’re done, let me know.

The browser takes that task and runs it in the background, using its own threads. Meanwhile, the JavaScript engine’s Call Stack is now empty and free to continue executing other synchronous code. It never blocked.

The Handoff (The Queues)

So the browser has finished its background task — the timer is done, the data has arrived. How does it hand the result back to JavaScript’s single thread?

It can’t just interrupt and shove the result onto the Call Stack. That would cause chaos. Instead, it uses a waiting line: the Task Queue (sometimes called the Callback Queue or Macrotask Queue).

When the asynchronous Web API task is complete, its associated callback function (e.g., the function inside setTimeout) is placed in the Task Queue.

But there’s also a second, high-priority queue for things like Promises. This is the Microtask Queue. Callbacks for .then(), .catch(), and async/await go here. Microtasks always run before any new task from the regular Task Queue.

So now we have:

1. A Call Stack that runs code.
2. Web APIs that handle tasks in the background.
3. A Task Queue for completed timers, clicks, etc.
4. A Microtask Queue for completed Promise actions.

One final piece is needed to make this all work.

The Conductor (The Event Loop)

The Event Loop is the orchestra conductor. It’s a simple, endlessly running process with one job: to orchestrate the movement of tasks from the queues to the Call Stack.

Its logic looks something like this, in a perpetual loop:

1. Is the Call Stack empty?
2. If yes, is there anything in the Microtask Queue? If so, push all of them, one by one, onto the Call Stack to be run.
3. If the Call Stack and Microtask Queue are both empty, is there anything in the Task Queue? If so, push the oldest one onto the Call Stack to be run.
4. Wait for the Call Stack to be empty again and repeat.

This simple process is the entire secret to JavaScript’s non-blocking behavior.

Tying It All Together

Let’s look at a classic example to see the whole team in action:

console.log("A: Script Start");

setTimeout(() => {
  console.log("B: Timeout!"); // This is a Task
}, 0);

Promise.resolve().then(() => {
  console.log("C: Promise!"); // This is a Microtask
});

console.log("D: Script End");

Here’s the step-by-step breakdown:

1. "A: Script Start" is logged. It goes on the Call Stack and comes right off.
2. setTimeout is called. The JS engine hands the timer (with its callback) to the Web API and moves on. The Call Stack is clear of it.
3. Promise.resolve().then() is called. The promise resolves immediately, and its .then() callback is placed in the Microtask Queue.
4. "D: Script End" is logged.
5. The main script is finished. The Call Stack is now empty.
6. The Event Loop asks: “Any microtasks?” Yes! It pushes the promise callback to the stack. "C: Promise!" is logged.
7. The Call Stack is empty again. The Event Loop checks the Microtask Queue again. It’s empty.
8. The Event Loop now asks: “Any tasks?” Yes! The setTimeout timer finished long ago and its callback is waiting. The callback is pushed to the stack. "B: Timeout!" is logged.

Final Output:

A: Script Start
D: Script End
C: Promise!
B: Timeout!

So, to answer the question: JavaScript is single-threaded, but it achieves asynchronicity by delegating. It hands off longer tasks to the multi-threaded host environment and uses the Event Loop to process the results of those tasks in an orderly, non-blocking way when its single thread is free.