✨♻️ JavaScript Visualized: Event Loop

If you're here in 2024 (or later), here's an updated blog post!](https://lydiahallie.com/blog/event-loop)

---

Oh boi the event loop. It’s one of those things that every JavaScript developer has to deal with in one way or another, but it can be a bit confusing to understand at first. I’m a visual learner so I thought I’d try to help you by explaining it in a visual way through low-res gifs because it's 2019 and gifs are somehow still pixelated and blurry.

But first, what is the event loop and why should you care?

JavaScript is single-threaded: only one task can run at a time. Usually that’s no big deal, but now imagine you’re running a task which takes 30 seconds.. Ya.. During that task we’re waiting for 30 seconds before anything else can happen (JavaScript runs on the browser’s main thread by default, so the entire UI is stuck) 😬 It’s 2019, no one wants a slow, unresponsive website.

Luckily, the browser gives us some features that the JavaScript engine itself doesn’t provide: a Web API. This includes the DOM API, setTimeout, HTTP requests, and so on. This can help us create some async, non-blocking behavior 🚀

When we invoke a function, it gets added to something called the call stack. The call stack is part of the JS engine, this isn’t browser specific. It’s a stack, meaning that it’s first in, last out (think of a pile of pancakes). When a function returns a value, it gets popped off the stack 👋

The respond function returns a setTimeout function. The setTimeout is provided to us by the Web API: it lets us delay tasks without blocking the main thread. The callback function that we passed to the setTimeout function, the arrow function () => { return 'Hey' } gets added to the Web API. In the meantime, the setTimeout function and the respond function get popped off the stack, they both returned their values!

In the Web API, a timer runs for as long as the second argument we passed to it, 1000ms. The callback doesn’t immediately get added to the call stack, instead it’s passed to something called the queue.

This can be a confusing part: it doesn't mean that the callback function gets added to the callstack(thus returns a value) after 1000ms! It simply gets added to the queue after 1000ms. But it’s a queue, the function has got to wait for its turn!

Now this is the part we’ve all been waiting for… Time for the event loop to do its only task: connecting the queue with the call stack! If the call stack is empty, so if all previously invoked functions have returned their values and have been popped off the stack, the first item in the queue gets added to the call stack. In this case, no other functions were invoked, meaning that the call stack was empty by the time the callback function was the first item in the queue.

The callback is added to the call stack, gets invoked, and returns a value, and gets popped off the stack.

---

Reading an article is fun, but you'll only get entirely comfortable with this by actually working with it over and over. Try to figure out what gets logged to the console if we run the following:

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

Got it? Let's quickly take a look at what's happening when we're running this code in a browser:

1. We invoke bar. bar returns a setTimeout function.
2. The callback we passed to setTimeout gets added to the Web API, the setTimeout function and bar get popped off the callstack.
3. The timer runs, in the meantime foo gets invoked and logs First. foo returns (undefined),baz gets invoked, and the callback gets added to the queue.
4. baz logs Third. The event loop sees the callstack is empty after baz returned, after which the callback gets added to the call stack.
5. The callback logs Second.

---

Hope that this makes you feel a bit more comfortable with the event loop! Don't worry if it still seems confusing, the most important thing is to understand where certain errors/behavior can come from in order to Google the right terms efficiently and end up on the correct Stack Overflow page 💪🏼 Feel free to reach out to me if you have any questions!

Comments

[Carlos Trapet]

Good stuff, Lydia! You have a very nice and straight-to-the-point way of expressing concepts, I'd love to read some more posts of yours, if you do have any!

[Lydia Hallie]

Will post them soon 😎

[Dayvster 🌊]

You did a fantastic job of explaining and animating this.

[Max (he/his)]

Good post, I really appreciate the effort you do to explain the things :)

[Rafael Beckel]

Interesting article! What did you use to animate the gifs?

[Lydia Hallie]

As a true professional I use keynote and screen record it lol

[squidbe]

Professional enough!

[Elango Sundar]

Nice awesome articles and visullay explained the event loops :)

[thebilson]

I'm also a visual learner, so this was very helpful. I'm still early on with JavaScript and it's challenging to understand it all; are there any books out there for us visual learner that you might recommend?

[Anoop Sivadas]

Try the book written by a John duckett

[Vanessa Osuka]

So it's safe to say the purpose of the event loop is to prevent any callback clashes? 🤔

[Lydia Hallie]

Hm no, not really. Imagine we have 4 tasks, and the 2nd tasks needs a delay. If this delay would've happened on the main thread, nothing would've been able to run on the thread while we were waiting:

However, the web api gives us some sort of asynchronous behavior by letting us put stuff "to the side" so to say. We can now keep on running other tasks, thus keeping an interactive UI, while tasks are running in the background:

Hope this somehow made sense haha I just woke up so my illustrations may not be optimal 😜

[Stanley Sathler]

So can we say that preventing callback clashes is the queue's job, instead of event loop's one?

[DevWorksSimone]

Great!

[Stanley Sathler]

Thank you so much for the illustrations, Lydia! Very helpful, indeed!

One question: what happens when the main thread is blocked - i.e. the UI freezes? Would the whole interaction within that viewport be blocked - e.g. cursor wouldn't change after hovering a link?

I think I've never faced this situation before, so I'm curious how to identify such situation. Is there any way to simulate a huge processing in order to freeze my UI, just to see that?

Thanks in advance!

[Pankaj Kumar]

Just write a for loop which is printing millions numbers. Call this function on any click function. You will see the effect.

[bru]

Hi, you can try this:

        function wait5seconds() {
            const plus5seconds = new Date().getTime() + 5000;
            while ( plus5seconds > new Date().getTime() ) {}

            console.log( 'wait5seconds end' );
        }


        function clickHandler() {
            console.log( 'click event' );
        }

        document.addEventListener( 'click',
            clickHandler ); // al comunicarme con la API del DOM estoy saliendo de JS 

        wait5seconds();
        console.log( 'end script execution' );

Execute this script, and press a lot of clicks, the clicks events will appear at the end ( because the dom events are push into the queue.

I think that what you need to take into consideration is when you are performing a task that it might take some time, that might block the UI.

[GaurangDhorda]

In this particular case de-bouncing is useful when we click on button..

[DevWorksSimone]

I love gifs! Thanks for explanatio ! Not programming in javascript but was very interesting ti read!

[Eugene Karataev]

Thanks for the great article and animations!
It's interesting why "event loop" question is so common on interviews, if it's job is just to transport code blocks from the queue to the call stack. I think better question would be to ask to describe how the JS mechanism works as a whole thing with call stack, web api, queue and event loop.

[Logan]

Hi, Lydia Hallie, it is a great article.

Can I translate this article into Chinese to help more Chinese developers(With original author and link, of course).

[Lydia Hallie]

Absolutely!

[Jonas Røssum]

Really nice article!
One thing I was confused about was

invoke bar. bar returns a setTimeout function.

Doesn't setTimeout return an id that you can pass to clearTimeout? 🤔

[Ibrahim Joseph M.]

Yes, It does Jonas, so lets say

let id = setTimeout( () => {
return "hey"}, 1000);

console.log(id) // you will get 1

let id2 = setTimeout( () => {
return "hey"}, 1000);

console.log(id2) // you will get 2

[thamer belfkih]

thank guys to point out this detail, in the same context what's the purpose of this Id and it is used by the web API or the call stack for some purpose? thanks in advance

[Douglas Fugazi]

Super nice explanation. I've learnt new things with this article. Thanks!

[bigleegeek1]

As a newbie to learning JS I appreciate your post and look forward to others.

bigleegeek

[Adnan Babakan (he/him)]

Hi Lydia
This an amazing visualization and demonstration of JavaScript event loop.

I want to ask you permission to translate this article to Persian (Iran's language) with the original post link of course so this article would be more accessible for other readers.

[Lydia Hallie]

Sure 😃