Hello and welcome to 42. I am drew random speaker presenting this talk, and we're going to talk about Javascript, code, JS and more in general. The event loop. Don't worry too much because this is an introductory talk. So if you don't know too much about this, not to worry. We're going to learn this thing together. The title of the talk is the event Loop fairy tale as you can see from the screen. And of course this takes place in a server far, far away. Now that we are at it, allow me to present myself. I am Lorenzo Pierre and I am the bard that shall sing this story to you. Although I'm not going to sing it, I'm just going to tell it. But bear with me, and if you have any questions whatsoever at the end of this talk or you feel that you didn't understand something or you want to know more about this, feel free to reach out. You will be able to send me a message on LinkedIn, Twitter or by email at any point. I'm very happy to chat with youll all, so just reach out. Nothing more to add on this. As you can see, I'm full stack wizard at Birdie, an incredible company in tech for good. We're going to know more about this in the next slide, but for now, bear with me. And I'm also schrolinger Hat Brotherhood's co chief, which means that I'm part of a community of people very interested in open source and the open source philosophy. And because of this we organize events, sessions, workshops and youre flagship event which is the conference open source day which is coming back in 2024 on the 7th and eigth of March. The call for paper by the way, is open. So if you want to reach out and also send a participation to that, you can do that. And the tickets are free. So if you want to grab them go to 2024 OSD Dev and you can find more information about that on the website. Also, you might not know me as by my tech nickname which is 404 answer not found but if you want, that is the nickname that I use throughout the Internet. So you can find more about me or my LinkedIn, Twitter and so on using that nickname and also on my website. 404 answer not found EU as for birdie, the beautiful company that I work for at Birdie, we envision a world in which we can all flourish with confidence as we age, and we are doing that by reinventing care through technology and enabling older adults to thrive at home. We are hiring engineers of all levels and also other positions outside of engineering. And we have clear skill requirements and salary, which can be found on our website, birdie care. So feel free to reach out if you are interested in hearing more about this, but let's get started with our talk and the story behind this. It was history. It was history because in a land far, far away, in a server far, far away, and so many years ago, you youll have the dragon blocks. And the dragon blocks were this magnificent, of course, but very, very powerful monsters that would block you, the programmer, from writing your code in an effective and efficient way. And for this reason came to existence. The knights of the thread. The knights of the thread were a group of valorous knights coming from all over the kingdoms of javadom, the kingdom of the Menaces and Pythonville. And what they would do is that they would fight all these dragons that would try to block the joyful life of some of the programming nations. How did they do that? Well, depending on where the knight would come from, as for example, the kingdoms of the Manices, they youll have different methodologies to fight the blocking dragons. The kingdom of the manices had magics called, named Posix threads, for example, which they would summon to avoid blocking, while Jaladon, for example, founded a new order of knights and wizards called the Nio Order. As for Pythonville, they invented a new scroll that the knights could bring along, called Asyncayo, that would help them predict and act before blocking events even occurred. But at some point, all of these knights and all of these nations started to hear about a new kingdom, raising up a kingdom that knew some kind of magic that would allow them to interact and avoid blocking operations altogether. And they were asking themselves, how are they doing it? How are they not getting blocked by these dragons of old, this blocking dragon? And, well, stories started to go throughout the lands, and finally a name came to be, and that name was the lands of promise. And although the pun is very intended, it was also the promise of a land where there would be no blocking whatsoever, because everything would work out eventually. Now, eventually is a very important word in this scenario, but we'll get back to this later. This land was filled with inhabitants named tusks, and they would all follow some very simple rules. But there was one, the most important one, that was very specific. And the specificity of this rule was, you shall not block the thread. The main thread. And what was this thread? Well, this main thread was this single thread castle that stood in the midst of this lands of promise. And in the single thread castle would leave two very important beings that we're going to talk a little bit more about later. But one of them being a very valorous knight, and the other one being the fairy of the event loop, and she was the one bearing all the magic that controlled the event loop. But let's stop for a minute, and before delving into which important characters were part of this realm, let's talk about the inhabitants. Now, the inhabitants that we are calling tasks, because that's what they like to be called, had a very unique way of handling their tasks. What I would like you to picture is that in this land, in these cities that were part of the land of promise, all the inhabitants, the tasks would be able to do multiple things at the same time. One would think concurrently. Is it true? Is it not true? That doesn't matter. You must think of this as a possibility. They were able, the inhabitants, the tasks, to do their things in the most efficient way. They knew what they wanted to do, and at some point, they knew that they would achieve the outcome that they hoped for. Now that we've said this, let's go and meet Astak circle. Astak is the valiant knight of asynchronous, the defender of the promised lands, and first of his name, liberator of processes, mother of. No, sorry, I've got that one wrong with know quite famous tv show. But really, what of stack was doing was defending the realm and the way tasks inhabitants were handling their own things, by making sure that each task would belong to each specific queue, and they could get, at some point, the outcome that they wanted. The job of Sir Colostag was very valorous, as in, he would make sure that everything would work perfectly fine, perfectly in order, and that everyone could get back to what they were doing without ever blocking the single thread, the main thread. And of course, he didn't do this alone. Alone, he wouldn't be able to do much, because he had the help of this incredible fairy that was actually running the event loop. But what is the event loop that we will call the loop from now on? Well, the loop was the heart of the village. Sorry. Every village that was part of the lands of promises had this central loop that was really the heart of the village. All the tasks, the Nabatans would go there, and they would have, like, different stands, and they could buy things, they could talk with people, and they could do anything in a synchronous way. Right. But the problem is that some synchronicity, as fast as it may be, can be very blocking at time. And as such, the tasks. The inhabitants knew exactly what they needed to do. If they were going to block, with some very heavy synchronous operation, the heart of the village. They knew that they couldn't just stand there. They knew that they had to accept that they had to go to on a travel of discovery to find out what they really wanted to do, how they wanted to do it, and then come back with exactly what they wanted to do. And for such reason, just outside of any of the towns of the promised lands, and outside of the event loop, was the desert of asynchrony. All the tasks would go and follow this path, because this path, which was known as the asyncali and the desert of asynchrony, was vast, stretching desert. And the tasks traveled this path, and it was a necessary tool, for they were bound to a magical destination, which was the forest of Libuvi. Now, while they were doing this path, they would reach the forest of Libuvi, which was also known as the forest of the thread pools. Within the expansive canopy of the forest of Libuvi, or thread pools, the rhythmic beats of the thread pool echoed. The thread pool, often depicted as a grand assembly of ancient trees, stood tall and firm. Each tree bore the hallmark of years of service, with gnar branches extending far and wide. At the foot of each tree, an elf of the threadpool diligently worked, weaving spells and executing tasks. So from these we can know that each task that went through the desert of asynchrony, youll at some point reach the forest of the thread pools. But what would happen this forest of the thread pools? Well, truly, they would meet the elves of the thread pool forest. And these elves were the only owners of the lib uv secrets, able to magically spawn as many threads as they like from their incredible thread pools. Of course, each forest was grandiose, but also as big as it could get. So there was a limited number of threads. At some point they could spawn. But that doesn't matter. What matters is that this thread were actually the one doing the hard work, the synchronous, the heavy work that those heavy tasks were bringing with themselves. And once that work was done, they would unspawn and just go out and back to the path that would lead them to the city. Each little task, with all of their callbacks done, would get back to the city so that they could take whatever that they wanted to do, and actually join the queue once more, so that they can actually enable themselves to live in the city again with whatever they wanted to do. Now of youre. This is incredible. This is efficient and asynchronous and non blocking so that the event loop could run infinitely and get back the tasks that were done at any point in time, because there was a trust that would be that at some point all of the tasks eventually would return with their results. And this was very important for the loop, for the fairy that was controlling the loop, and also for circle a stack that would then do its magic by bringing in the task results and actually apply them to the right cues. And this is all very magical and incredible. But we must also remember always that some creatures are to be feared, some others to be controlled. Blocking dragons should be understood, but never underestimated. What we want to see and learn from this slide is more of a cautionary tale to us. While the Node JS realm offers immense power and flexibility, it requires careful orchestration and vigilance. For in the world of asynchronous magic, even a single misstep can have dire consequences. But we must learn not to fear the dragons, but rather to accept their existence. Really, if we learn that there are dragon blocks, if we learn how to defend our systems against them, then we will have learned not to fear them, but actually maybe to befriend them. Who knows? Well, it's up to you, the user of Node Js, to learn more about this. But we've talked about the fairy tale. We've talked about very interesting characters, hopefully. But what is the event loop? Well, the event loop is comprised of many things, but let's talk about the phases that make up the event loop. There are mainly six phases that we can talk about, one being the timers. Then we have the pending callbacks. Then we have the idle prepare, the youll, the check, and the close callbacks. The timers phase handles callback functions of scheduled timers, specifically set timeout and set interval. It checks if the timer duration has been reached, and if so, executes its callback. Then we have pending callbacks. This phase handles I O related callbacks that were deferred from previous event loop cycles. The other one, idle and prepare, is only used internally. This is used to handle maintenance tasks, such as managing internal operations required for the upcoming I O operations or certain timers cleanup operations. But we must not worry too much about this. As for the poll phase, in this crucial phase, Node retrieves new I O events and executes their corresponding callbacks. This is where the event spends most of its time. If there are no pending timers or immediate callbacks, it's just running around waiting for things to happen if nothing is happening, of course. As for the check immediate one, after youll phase, node JS moves to the check phase, where it handles set immediate callbacks. And in the final phase, node JS handles close event callbacks. For instance, when a socket or a handle gets closed abruptly, the callback will be executed in this phase. This is all good. And of course, knowledge is everything, and there are many other things that can be learned. You are going to hear more and more about process next tick about set immediate about set timeout. And I think it would be good for you to actually study those things. But what matters the most is that you actually learn to reason about the loop. And how can we do that? Well, hopefully with some additional examples. So let's see what happens in the next slide. Well, there are many things that can be said about the loop. Sometimes very technical things. Sometimes people talk about the heap and where stuff exists, the hostack where stuff is cold and the actual code. But really, no one cares. If we imagine this as a tavern, you imagine like the hip is the place where all the mead is stuffed, the coal stack is the people at the bar actually waiting for their mead. And the coals are the actual order of the mead. Right. But no one cares, if you think about it, as long as the mead is the one that they wanted. No one really cares about it as long as they get it right. And so what should we get out of this? Well, I think we should simplify the event loop understanding, our event loop understanding to just a few phases. So let's get inside the loop. So what I would say is that there are only four important timers, queues, sorry, that you should think about. The first one is timers. Then we have callbacks. We don't really care about idle prepare because that's internal. So we don't really care too much about that. No need to remember that youre not ever going to use it. Then you have the pull phase and then you have the check phase. I would say the same for the close phase, because once youre out of the loop and you're closing out of your own program, do you really care about that phase? Youre closing your program at that point. What I would like to understand is this loop is not like very circular as it's shown sometimes, but it's mostly like going back and forth between one phase and the other. We start with timers. It goes to next tick or the microtasks, which really are the promises. And then the next tick or the promises go back to the callbacks, which go back to the next tick, or promises, which go back to either prepare, which go back to pool, which go back to next tick and check, and so on. And this goes on infinitely until we close and we go out of the loop. Once we've learned this and we know which phase is working at a certain point in time, we have all the knowledge we need to become the magicians, the wizards of the vent loop. Just to wrap our minds around this, let's do a simple exercise together. Which magic scroll would first be read by the mages first? The ancient scroll of set timeout with its callback function and a zero as time. The ancient scroll of set interval with its callback. The ancient scroll of process, next tick with its callback. The ancient scroll of set immediate with its callback or the borrowing ancient scroll of console log. So which one do you think is going to go first in order? Think about it a little bit, and if you know the answer, please do reach out and send me the answer on LinkedIn maybe, or Twitter and we can talk more about this. The answer is number five, the boring answer scroll of console log. And why so? Because console log is a synchronous operation which never gets inside the loop whatsoever. So we're not even using the event loop at this point because we're never going to get console log inside the loop unless console log is part of those FN callback functions which are called as part of something that is part of the event loop. Now, hopefully that was simple. What I would like to say is that the strength is found in the mind, but accrued with time. And this means that it just takes time to learn more about this and to actually get better knowledge and actually better at using node JS and JavaScript and the event loop in general. So keep practicing, and if you have any questions, just ask them either to me, to your seniors, to your peers, to anyone. Just do things and have fun while doing them, and you will have all the knowledge you need about the node js, event loop and node js in general. I am Lorenzo Pierre, the Bart that didn't sing this story, but hopefully you had fun listening to it again. I'm a full stack wizard at Birdie Schrodinger, head Brotherhood co chief, and also you can find me on LinkedIn, GitHub, and on my website. Answer not found EU and four or four answer not found is my name. If you want to get into open source, go to OSD Dev or 2024 OSD Dev, where you can find all the information about the upcoming conference that is going to be about open source next year in 2024. But most importantly, be thank you for coming to my talk. I hope you had fun. I hope you learned a lot of things and you learned how to have fun with the node JS vent loop. And if you have any questions, feel free to reach out and I'll be very happy to talk with you. Thank you very much for being here. Take care. Have the best day.