Event Loop

[00:00:00]
>> Will Sentance: Let's introduce one final piece of this puzzle, which is JavaScript's tool for doing that checking. How does it know that the call stack is empty? How does it know that global's finished running all of its code? How does it know that there's stuff waiting in the queue? It has a key feature that sits between our queue and our call stack and is checking. Before every single bit of code is run, checking, checking, checking, checking on repeat, it's looping, checking all the time.

[00:00:36]
Is our call stack empty? Have we finished running all global code? Is there something in our callback queue? Has, is our call stack empty? Have we finished running all global code? Is there something in our callback queue? It's looping over that every single time and saying, is there some new information, is there something that happened? Can anyone guess what the, yeah, Matt, microtask, we're going to see that one very soon.

[00:00:57]
Chris, can you guess? The event loop. The event loop. Don't, do not fear, Matt, we're going to see the microtask queue in a moment. It is the, where shall I put it? Let's put it on the, it is, there we go, it is the event loop. And its job is pure and simply to check on repeat, repeat, repeat, repeat, to check. Is my call stack clear of any code, any functions, execution context on it, has it finished running all global code?

[00:01:30]
Does my callback queue have something in it? Here is my call stack empty? Uh uh, sorry, callback queue, you've just gotta sit there waiting. All the way through, is my call stack empty? No, it's got blocked for one sec on it. Hit the end of block for one sec, does my event loop go, hooray, callback queue, you're good to go. Nope. Instead, it says, shoot, there's still a bunch more global code to run at console log, or a bunch more, one more function.

[00:01:53]
If there are a million, there's still a bunch more global code to run. Is my call stack empty? Uh, at the end of my, uh, when I finally finished running my console log me first, now my call stack is finally empty. My callback queue has my print hello function that's been there waiting since the very, very start, because it immediately finished and was immediately queued up, ready to go, I'm ready to go.

[00:02:22]
But it couldn't enter until the event loop saw that the call stack was empty, all global code had finished running, and finally, it will grab our print hello and shoot, I should have dequeued it, it will remove it from the queue and add it to our call stack. We are now able to hit our callback queue, add it to our call stack and execute our code. Here we go, people. So let's do thumbs in a second on the expansion of our core JavaScript model, from having our synchronous code execution, running through the code line by line, our synchronous execution with the memory and the call stack, to having a whole new package of tools available to us, our web browser features or in Node, and Node background features.

[00:03:10]
And our ability to trigger them from within JavaScript with functions that look a lot like JavaScript. In fact, I call them facade functions for that reason, because they even get called with parens in the same way, you pass stuff into them, no problem. We find out about them on MDN we need to because the names on MD, the names of the features are often different to the labels within JavaScript, uh, and if that work's happening in the background, we do need some rules and structures for how to get that work back, get the outcome of that work, sorry, back into JavaScript, because we must have predictability within JavaScript.

[00:03:48]
What do we have? When the background work is done, any associated function that we want to have run back in JavaScript, that's triggering JavaScript code. That's triggering JavaScript single thread of execution. We better have a place to queue that work up, so it doesn't just land in any moment. As we heard from Chris, as we heard from Joe, we heard from Tenzin. Wait, can it just come back on any time?

[00:04:12]
And as we heard from Tenzin, what if it finished immediately? Surely we get to run it right there and then. Uh uh uh. Instead it goes and sits in the callback queue until the event loop that is doing every single tick of our code running, every single task we do on the code within this environment, it is checking. Should I run anything out of the callback queue? Not until two strict rules, my call stack is fully empty and all my global code has finished running, at which point I can grab my print hello function and put it into the call stack.

[00:04:46]
The event loop is checking just our call stack, we might see there might be some, not sorry, just our callback queue, we might see that there are some other. And if you wanna go and watch the Node hard parts, well, I don't wanna give it away, so. I hope there's only one queue, that's all I'm going to say. I can only imagine. It would be very bizarre if in Node, there were up to four or five different, okay, alright.

[00:00:00]
Uh, you imagine having to blackboard through Node hard parts. Imagine. I can only imagine there must be one queue. Why would you need more?