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:
Main tasks (Synchronous):
Stuff likeconsole.log()
runs first. These are the direct, in-your-face tasks.Microtasks (Promises):
Promises come next, even before timers. It’s like they’ve got a VIP ticket.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 it0ms
, it waits.
Breaking Down the Code
Let’s see what’s happening step by step:
-
Promise Created:
-
console.log(1)
runs immediately. -
setTimeout(() => { ... }, 0)
gets added to the task queue. -
console.log(2)
runs immediately.
-
-
Promise
.then()
:- The
.then()
callback is added to the microtask queue.
- The
-
console.log(4):
- Runs directly since it’s part of the main script.
-
Microtask Runs (VIP):
- The promise resolves, so the
.then()
callback logs"success"
.
- The promise resolves, so the
-
Task Queue Runs:
- The
setTimeout
callback finally gets its turn: logs"timerStart"
and"timerEnd"
.
- The
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:
- Synchronous code: People who bought fast-track tickets—they’re first, no debate.
- Promises: People with VIP passes—they’re next in line, even if they came late.
- 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:
-
console.log(1)
(Synchronous) -
console.log(2)
(Synchronous) -
console.log(4)
(Synchronous) -
"success"
from the.then()
(Microtask) -
console.log("timerStart")
(Task queue) -
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!
Checkout : Meetman - AI Powered Google Meet
Portfolio : Sourav Mishra
Top comments (0)