Kevin Powell - Community•2w ago

Event loop in JS

Task Queue (Callback Queue): Stores tasks waiting to be executed after the call stack is empty. These tasks are queued by setTimeout, setInterval, or other APIs.

Does someone know why the call stack should be empty for the callback queue events to take place?

18 Replies

ἔρως•2w ago

those are all tasks that can be done later

FakerOP•2w ago

yeah, the thing is, consider this example:

console.log("Start");

setTimeout(() => console.log("First timeout"), 0);
setTimeout(() => console.log("Second timeout"), 0);

console.log("End");

console.log("Start");

setTimeout(() => console.log("First timeout"), 0);
setTimeout(() => console.log("Second timeout"), 0);

console.log("End");

I first thought that it would be sequential here since timeout is 0 but start is first followed by end then first timeout and second timeout I didn't understand why it's like that though :c, what would break if this wasn't the case I found a nice visualiser https://www.jsv9000.app/

13eck•2w ago

The reason is that the event loop is single threaded. It can't grab anything from the event queue until the call stack is empty. The call stack has priority, whatever is on it is done first, on a LIFO order. If there's nothing in the stack, then it checks the callback queue (well, it checks the promise queue first, callback queue second)..

ἔρως•2w ago

lifo means "last in, first out"

13eck•2w ago

Yes, thank you As opposed to FIFO: First in, first out. LIFO is a stack, FIFO is a queue

FakerOP•2w ago

yeah just read that, the thing is, whatever is in the call stack is calls from JS engine itself but whatever is in the event queue or callback queue is from the browser apis like web apis? Each one goes into different queues?

13eck•2w ago

There are three main places that functions go into. In order of importance: 1. The Call stack 1. The promise queue 1. The callback queue Nothing can happen until it hits the call stack, so that's the most important category. Note that this is a stack, not a queue. The call stack is synchronous, last-in first-out. Which is why you can call a function from within another function and have the inner fuction resolve first: it gets put on the top of the stack and run, then when it pops off the stack the rest of the outer function runs. After that, is the promise queue. Any Promise.then(), Promise.catch() , or Promise.finally() goes in this queue. If this queue is empy the runtime checks the callback queue. The callback queue is where everything else goes. setTimout, setImmediate and for Nodejs and similar, file reading/writing. Basically anything that takes a callback that isn't a promise has that callback thrown in here. https://youtu.be/eiC58R16hb8?si=CRr73fjkL-l17E8X

Lydia Hallie

YouTube

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

Learn how the browser event loop, task queue, microtask queue, and Web APIs work together to enable non-blocking, asynchronous JavaScript. - https://www.patreon.com/LydiaHallie - https://buymeacoffee.com/lydiahallie - https://twitter.com/lydiahallie - https://www.linkedin.com/in/lydia-hallie/ - https://instagram.com/theavocoder Timestamps: 0:...

13eck•2w ago

-# Note that in the video the Promise queue is called the microtask queue. Each JS runtime has a different name for it, but it's the queue promise callbacks go into.

13eck•2w ago

Or, if you want the TL; DR version: https://youtube.com/shorts/Q4WHvC_Wib0

Lydia Hallie

YouTube

The event loop in 60 seconds! #shorts #javascript

FakerOP•2w ago

yeah just watched that 😂 yep I see, for node JS also we have an event loop, why is that though?

13eck•2w ago

Because Nodejs is JS. JS has an event loop What would be the point of having a non-browser JS runtime if it didn't run JS? One of the biggest draws of Node (and other back-end JS runtimes) is that it's JavaScript. Front-end devs don't need to learn another programming language. One set of coding skills covers the entire stack.

FakerOP•2w ago

yeahh I see Thanks !

13eck•2w ago

Do note that because of this, setTimeout is not a timer. Rather, it's a minimum time. If you set a timeout for, say, 5 seconds and then spend the next 60s calculating the Fibonacci sequence then the timeout won't run until the call stack is empty. So even though the timeout was set for 5sec it won't run until after 60s whe the call stack becomes empty.

ἔρως•2w ago

setInterval is different, by the way it's meant to run the task every x milliseconds and if im not mistaken, it executes as soon as possible

13eck•2w ago

But it still can’t run if the call stack is full.

ἔρως•2w ago

i always had the idea that it stops everything, but i need to test

13eck•2w ago

It doesn’t. JS doesn’t have the ingress to store the program state at random intervals like that The only thing that stops the world in JavaScript is the garbage collector

ἔρως•2w ago

you are right, it doesnt stop some events can run while other events are stuck (for example, in an alert) the resize event is an example of that

Gaming

Programming

Event loop in JS

Did you find this page helpful?