Maybe you think that when your setTimeout expires its times it will run immediately, right? Wrong! I will explain. There’s a lot going on under the hood before your callback actually runs.

JavaScript uses a message queue to handle their events. Everytime you fire an event in JavaScript it goes to a queue where it stores a bunch of information about your event, such as: the callback which will handle the event and all the event firing data. 

This queue is organized by first-in, first-out (FIFO), which means, the first event message will be the first to be processed by the runtime.

The JavaScript event loop requires the stack memory in order to work. All the process of interpreting the JavaScript language runs around the stack and the heap.
In order to JavaScript process your event handler it needs to load your function into the stack, and to load a function into the stack you need to call it.

So what does JavaScript do?
JavaScript does not prioritize your events messages, it prioritizes its call stack. Which means JavaScript will run your event message just when stack memory is empty! 

Run this sample: 

<pre>
<code class="code">
function bench() {
 let milisec = 150;
 setTimeout(() => console.log("PRINTED"), milisec)
 let count = 0;
 while (count < 600000000) { count++ } 
 console.log("Count Finished ")
}
</pre>
</code>

This code prints two messages, but asynchronously.
As you can see, our setTimeout has a delay of just 150ms, very short. Which means it is almost instantaneous! 
But when you run our code below it takes some time to run it! 
Why? As I mentioned before, the JavaScript runtime just runs our event message when our call stack is totally empty. 


To prove this, we’re gonna see another example. 


Run this: 



<pre>
<code class="code">

function benchmark() {

 function loop(num = "1") {
	let count = 0;
	while (count < 600000000) { count++ }
	console.log("Loop " + num + " Finished")
 }

 let milisec = 0;
 setTimeout(() => console.log("PRINTED"), milisec)
 loop("1");
 loop("2");
}
</pre>
</code>


Could you see? Even with 0 delay our output is: 

Loop 1 Finished
Loop 2 Finished
PRINTED

This happens because during the execution of the benchmark function, our stack still remains a frame, which is the benchmark function itself. JavaScript ran our setTimeout callback just after the frame of the benchmark function had gone. So take care with setTimeout, the time set by you, it is not a guaranteed time, it is a minimum time!

I hope you found this article interesting and helpful!
Thank you for reading, I really appreciate it!

Henderson's Blog

Complex Software Engineering

How setTimeout works under the hood

Author @DevHenderson