Hi, I flew in from Australia the day before yesterday I’m not saying that I’m the most jet lagged person here, but I would appreciate it if you could all just put in a little bit of effort to laugh at my jokes That would really make things easier for me! So, the event loop A couple of years back, here at this very conference, a guy by the name of Phil Roberts did a talk called “What the heck is the event loop anyway?” If you haven’t seen it, I highly recommend you check it out It is on the JSConf YouTube chapel It is pretty fucking exciting because it catches on fire! In case you haven’t seen it, though It is an overview of the event loop, the different components, and how they work together If you haven’t seen it, we will do a quick overview of the things that are relevant for today, and then we are going to do a deep dive into specific parts of the event loop So, you can think of the event loop as, like, the main function of the browser It’s just an infinite loop It’s going to grab a task off the task queue, and it’s going to run that task Which is great, but what is a task? So a task is how JavaScript gets run If we have a bit of a script like this, we can see JavaScript in there The browser will parse this script tag and create the task So the code with the dark background is going to be a task When it gets run, it’s going to create a variable, it’s going to do something, and it’s going to register this event listener, and, then, whenever the browser gets a keydown event, the bit of blue is going to run as a task Every bit of JavaScript that runs as a task could be a script or could be a callback What does execute task do? It runs the code What about the taskQueue That’s what we are going to look at today We are going to look at taskQueues in the context of browsers, and look at Node, and we are going to have a real quick look at web workers Constitutional So what is a taskQueue and what is it for? It’s where your code goes, where your JavaScript goes while it’s waiting to execute So, like before, we could parse a script tag, we could have callback on a click event, we could have a callback on a set time out They’re going to go into our queue there, and they’re going to get executed The important thing is that it is a queue, so things are going to get executed in the order that they arrive – first in, first out – and the other important thing is that a task is going to run from start to finish There is no interrupted JavaScript You don’t have to worry about concurrency, locking, or any of that rubbish It is super easy Cool That’s our event loop It turns out, though, it’s a little bit more complicated than that You see, the taskQueue works in conjunction with the rendering pipeline The rendering pipeline is what it responsible for painting things in the browser window, so you make changes to the DOM, you update your style, and then the rendering pipeline runs and shows it on the screen So, the webbed pipeline can run after a task finishes The task finishes, the rendering pipeline can run, but browsers are pretty clever, right? They don’t like to do work that they don’t have to do, and there is really no point running the rendering pipeline unless the screen’s about to refresh, so your average screen refresh s 60 times a second, once every 16 milliseconds, so, if we run a task, the rendering pipeline is going to wait that 16 milliseconds before it runs If it is not obvious, this is the slowed down version It is turns out it is hard to see, at 60 frames a second Sitting around doing nothing all that time is a bit of a waste, so, in reality, the browser’s going to run a where did you go of tasks, and then run the rendering pipeline The important thing is that the rendering pipeline can’t run until the task finishes If you’ve got a task that takes a really long time, the rendering pipeline has to wait A couple of milliseconds here and there isn’t going to matter If you take tasks that take a lot more than 16 milliseconds, your web page is going to start dropping frames and start running like this If you do have long-running tasks, you can split them up, so you can create new tasks using something like setTimeout You can use would be workers because that’s what they are for

So now, an event loop looks a bit like this We’re going to run an infinite loop, pick a task off the task cube, and run that task, and then, if we’re ready to repaint, we will repaint That’s cool, right? It turns out, it’s more complicated than that, if you have a look at the spec, which I’m sure we do in our spare time, you will see that an event loop it have one or more taskQueues At this point, what I will do is I will have a look at an query … . [Sound distorted] So, instead, we are going to look at a theoretical browser with multiple taskQueue s To be clear, this is the example that is give in the spec of having multiple taskQueues, so I didn’t make it – somebody else made it up This browser prioritises mouse-click event It has got two taskQueues there One where our mouse click is going to go and another queue where everything else goes This is really simple, it’s like the business class line at the airport It’s going to run all of the tasks in the mouse-click queue, and then the tasks in the other queue It doesn’t affect the rendering pipeline which will run after each task in it wants to Super simple It doesn’t have to be like that, right? The browsers can actually execute the queues in any order they like, so we could have taken two off the mouse click queue and three off the other queue – whatever we like The queues can be executed in any order But, the queues still do have to be queues So the tasks have to be executed in the order that they arrive First in, first out All of our mouse-click events have to go in that queue Node uses a specific queue for timeout event, so all of the timeout events have to go in that queue So this is how our event loop looks now: we’ve got an infinite loop, we are going to pick a queue, grab a task, and then it’s time to repaint, and we will repaint This is still straightforward, right? It turns out, it’s a little bit more complicated than that, though We also have microtasks What is a microtask? For the purposes of this 20-minute talk, a microtask is a promise There are other things that generate microtasks but 99.9 per cent of things that you do it’s going to be promises So our microtask queue is in yellow there next to the rendering pipeline, and we have a bit of code, it’s going to run We have a promise that resolves, it goes in the microtask queue Now, the microtask queue has a couple of special properties First of all, it runs after every task, so you finish a task, then you run the microtask queue Even if the rendering pipeline would like it run, it has to wait until the microtask queue finishes If we have multiple tasks in the microtask queue, they’re all going to run If we add more while we are running it, those will have to be run too, so this has some important implications for how things run Let’s have a quick look at the difference between how tasks run and how microtasks run So this bit of code generates tasks I click the button, it’s going to principle out the number of tasks that it has run, and then it’s going to generate another task, which is going to print out the number of tasks that is run so on, and so order infinitely We can see it running, counting tasks, everything is great, I can select text, I can click stop I can’t click start again, because I didn’t implement that But, if we look at the same thing with microtasks, things are a bit different So, if I start, so this is the same code, right? It is a coding and microtask, which is going to print out the number of microtasks that have run, and then create another microtask, and keep looping, the same as the set setTimeout

but with promises If I click start promising, we can see everything has immediately gone to shit The button has clicked but it hasn’t unclicked, right? The cursor, which you can’t see there, it’s still the little hand I can’t select text I definitely can’t click stop, which wouldn’t have helped because I didn’t implement it anyway, it’s like I knew what was going to happen This page is kaput If we wait a little bit longer, Chrome will realise and tell us tell us but I don’t have that kind of time What happened there? Exactly like we saw in the example, we are stuck, just dealing with the microtask queue So the rest of the event loop is blocked, we can’t re-render the page, we can’t do anything else, we are stuck in the event loop – stuck in the microtask queue So, yes Cool This is how our event loop looks now It’s an infinite loop We are going to pick a queue, a task off that queue, and run it As long as there are microtasks to round, we’re going to do microtasks, and, then Would it be fair to say that is done, if it is time to repaint, we will repaint Cool, so this is starting to look a little bit complicated but it turns out it’s just a little bit more complicated than this We also have the animation frame callback queue which I’m going to call the animation queue, because, if I keep saying animation frame callback queue, this talk won’t get finished in time for lunch! So you can add things to the animation queue by calling request animation frame and passing a callback Why would one do such a thing? I’m using it here to run the animation of the browser running into the browser right-hand window into the pipeline I have my browser window and pipeline, and I remove a class which resets the frame, and then I add the slide class to the window which gives it a – which makes is slide down, through the magic of transitions If I did it like this, as I said before, browsers are clever, and they like to be helpful If I wrote this code, the browser would look at it and say you’ve removed the class, and then you’ve added the same class back again That’s the same as doing nothing So, let’s just do nothing Instead where I have to make sure that things occur after – so to do one, I need the browser, the window to refresh, and then I need to do the next thing We have a look at how that works We’ve got our animation queue there in green beside the rendering pipeline I’ve got my scripts running, and I call request animation frame which adds something to the animation queue You can see it’s going to sit there, and nothing’s going to happen until we’re ready to repaint, and then we will run the animation queue, and then we will repaint the browser Like the microtask queue, the animation queue has a couple of special properties If I have multiple things in the animation queue when it is ready to run, I’m going to run all those things But, if I add more things to the animation queue while it’s running, I’m not going to run those guys The reason for that is that, if you’re creating animations, you want to say this is what I want to do in this frame, and then you’re going to set up what is going to happen in the next frame but you don’t want run it, right? You want to wait until the window has refreshed Cool So, this is what our event loop looks like now It’s an infinite loop We’re going to pick a queue We’re going to grab the first task off that queue, and we’re going to run the task Then, as long as there are microtasks, we’re going to run all those Then, if we’re ready to repaint, we’re going to grab the animation tasks that are currently in the queue, and we’re going to run all of those, and then we’re going to repaint And that is as complicated as it gets But, what about node? First of all, good news Node is a lot simpler than a browser It has no script-parsing events You’re not picking JavaScript out of HTML all over the place, you just give it a JavaScript file and it runs it There is no users clicking on shit all over the place You don’t have to worry about animation framework callbacks because there’s no rendering pipeline There is also another β€” important difference with Node: the browser event loop is like a merry-go-round

It just keeps going round and round and round The Node event loop, it’s more like a roller coaster It is going to run through one loop, and there’s more stuff to do, it will run through another loop Once it’s done, that’s it It’s done So, the Node event loop: Node has three queues that are interesting enough to talk about today It’s got one queue for all of your event callbacks, so your XHR requests, your disk reads and writes and that stuff will go in the first queue They’re called phases in nodes The second phase is the check phase And the third phase is your timers this that’s all of your timers for callback and set interval will go into that third queue Node is going to run everything in the event callback queue; it’s going to run then everything in the check queue Once that is done, it’s going to run everything in the timer queue Then, if there is more stuff, it will loop back around and run through the queues again As soon as there is no task in any queues, and there are no event waiting anywhere, it will finish It will end So, how do you add stuff to the check phase? You can add things to the check phase queue by calling setImmediate and parsing a callback setImmediate is the same as setTimeout with a time of zero, but because of the way the queues work, if you call setTimeout with a time of zero, and setImmediate, your setImmediate is going to run first Node also has promises Just like the browser, and Node promises work just the same as browser promises β€” after each task finishes, we will run the promise microtask queue Node also has another micro task queue which is the nextTick queue You can parse a callback It works just the same There’s nothing really interesting there The major difference is, if you have both promises and nextTick callbacks becomes all your nextTick callbacks will run before your promises, but that’s pretty much it The only new things, different things in Node are setImmediate and process.next tick Pro why are they named like that? It turns out naming things are hard You guys all know the two hard problems in computer signs, right? Validation, and naming things, and off by one errors So this is our Node event loop It’s only going to run while there are still task It’s going to pick a queue, and then, while that queue has more tasks, it’s going to grab the next task in that queue, it’s going to run that task, and then while the next tick queue has more tasks, it’s going to run all the next tick queue tasks, and then, while the promise queue has more tasks, it’s going to do the promises So that just leaves web workers Anyone who is not familiar with Australian wildlife, this is a redback spider Unlike most Australian wildlife, they’re not that dangerous Nobody has died from a redback spider bite since the 1950s Probably don’t get bitten by one, though So web workers: web workers turn out to be dead simple Each web worker run in its own thread It has got its own event loan, got its own stack, task queue β€” everything just runs on its own It’s even easier than Node So there are no script tags Again, you parse in a JavaScript file There are no user interactions Web workers aren’t allowed to manipulate the DOM so you don’t have to worry about any animation frames or anything like that If we look at a demo, we can generate a task, call a setTimeout, make HSR requests, we can send and receive post-message events, so, post-message is how your web worker communicates with the browser window

And we can make promises It’s β€” that’s it It’s just really easy Yes So, that’s a event β€” that’s the event loop Things to remember: long-running tasks will make your page run like a wonky cat Promises and nextTick tasks can make it run like a dead cat Make sure you break your tasks up into small pieces and don’t have infinitely recursive promises and nextTick tasks Node is a bit different to the browser It’s going to run through the event loop only as long as there are things to do It has got those three specific tasks, and it’s got setImmediate and process.nextTick Web workers do their own thing, in their own event loop, and completely separate from anything else that is going on Remember, the event loop is more exciting than you can possibly have imagined! Thank you [Applause]

You Want To Have Your Favorite Car?

We have a big list of modern & classic cars in both used and new categories.