What Does setTimeout(..., 0ms) Really Mean in JavaScript? (Event Loop Explained!)

What Does setTimeout(..., 0ms) Really Mean in JavaScript? (Event Loop Explained!)

Alright, let’s break down this whole⁣ setTimeout thing with 0ms. At first glance, you’d think, “Bro, 0ms means it’ll run immediately, right?” But JavaScript has its own vibe, and 0ms isn’t as instant as you’d expect. Let’s figure this out together.

The Code:

Here’s the code we’re dissecting:

const promise = new Promise((resolve, reject) => {
  console.log(1); 
  setTimeout(() => { 
    console.log("timerStart");
    resolve("success"); 
    console.log("timerEnd");
  }, 0); 
  console.log(2); 
});

promise.then((res) => {
  console.log(res); 
})

console.log(4);

And the output?

1  
2  
4  
timerStart  
success  
timerEnd

The Big Question: What’s Happening with 0ms?

When you see setTimeout(() => { ... }, 0), it feels like the code inside will run immediately after 0ms. But nope, JavaScript is like, “Bro, I’ve got my own system, wait your turn!”

JavaScript’s System: Event Loop

JavaScript doesn’t just run code directly—it has a cool system called the event loop to handle tasks. Think of it like this:

1. Main tasks (Synchronous):
   Stuff like console.log() runs first. These are the direct, in-your-face tasks.

2. Microtasks (Promises):
   Promises come next, even before timers. It’s like they’ve got a VIP ticket.

3. Task queue (Timers like setTimeout):
   Timers go to the back of the line and only run after the microtasks are done. Even if you give it 0ms, it waits.

Breaking Down the Code

Let’s see what’s happening step by step:

1. Promise Created:

   • console.log(1) runs immediately.

   • setTimeout(() => { ... }, 0) gets added to the task queue.

   • console.log(2) runs immediately.

2. Promise .then():

   • The .then() callback is added to the microtask queue.

3. console.log(4):

   • Runs directly since it’s part of the main script.

4. Microtask Runs (VIP):

   • The promise resolves, so the .then() callback logs "success".

5. Task Queue Runs:

   • The setTimeout callback finally gets its turn: logs "timerStart" and "timerEnd".

Why Doesn’t 0ms Mean “Right Now”?

Even though you said 0ms, the setTimeout is always deferred. JavaScript pushes it to the task queue, no matter what. The system first clears all synchronous tasks and microtasks (promises) before touching the task queue.

So, in simple terms:
0ms isn’t about the time—it’s about waiting for your turn.

Think of It Like This

Imagine you’re in a queue for a rollercoaster:

1. Synchronous code: People who bought fast-track tickets—they’re first, no debate.

2. Promises: People with VIP passes—they’re next in line, even if they came late.

3. Timers (like setTimeout): Regular people with no passes. Even if you tell them, “0ms wait,” they still have to stand in the regular queue.

Final Output Recap

Here’s the order of events in our code:

1. console.log(1) (Synchronous)

2. console.log(2) (Synchronous)

3. console.log(4) (Synchronous)

4. "success" from the .then() (Microtask)

5. console.log("timerStart") (Task queue)

6. console.log("timerEnd") (Task queue)

Why Does This Matter?

Understanding how 0ms really works helps you write better asynchronous code. It’s also a cool trick to explain to your friends when they’re debugging random delays in their JavaScript.

So next time you see setTimeout(() => { ... }, 0), just remember—it’s not about the time; it’s about priority!