Hello everyone How’s it going didn’t get my slide clicker out Yeah, this is my first time in Singapore It’s yeah, it’s nice oh This is already going well if I get an applause for that. That’s fantastic It’s like I haven’t really looked around yet like I landed just before the conference so I can’t say I’ve really experienced it yet But I’m gonna stay on for a few days afterwards, and you know and have a proper explore I brought my partner along with me as well And I have to say that was a big mistake a huge mistake Because she’s been really looking forward to this trip right and especially over the last couple of weeks she’s been saying things like I don’t know two weeks till we go to Singapore one week till we go to Singapore five days to Go four days to go, and I could you could you please not do that because what I’m hearing right is Five days you only have five days to finish your talk four days three days. You’re still not ready Are you said the worst project manager ever just like taunting me, and how unprepared I am, but then she’s brilliant like she knows how to she knows how to put up with me because Because I stress right. I stress pretty easily. I stress about things that aren’t really problems. I stress about things that are really nothing to do with me and Someone posted this picture on Twitter last week He’s holding a MacBook between two fingers above concrete! I have not slept since I saw this picture I stress about code like this right and firstly because there’s no semicolons. Give me a cheer if you use semicolons in JavaScript Yes, good to hear the rest of you are monsters But that’s not the main thing that stresses me out late. It’s because it’s adding stuff to the DOM and Then hiding it like presumably to show it some time later like on click or something and that stresses me out because it’s like can we be sure that the user’s not going to see like a flash of that element before it’s hidden and And I’ve never been able to recreate this problem I’ve never seen it happen, but I you never know when it comes to race conditions, so I always just Swap those lines around you know just so I can get some sleep But really there’s no race condition here because the timing of running code and rendering is always all tightly defined and mostly deterministic And that is thanks to the event loop, and if I do a half decent job in the next 30 or so minutes You’ll know why things run in the order they do and I don’t know it might even make sense, but there’s no promises there So web pages have a thing that we tend to call the main thread Here’s the main thread We call it the main thread because loads of stuff happens here is where JavaScript happens. It’s where rendering happens. It’s where the DOM lives And this means that the bulk of your stuff on the web has a deterministic order we don’t get multiple bits of code running at the same time like trying to edit the same DOM and Giving you a world of horrible race conditions But it does mean that if something on the main thread takes a long time and by a long time I mean like 200 milliseconds That’s a long time in terms of user interaction Then it becomes really noticeable because it’s blocked loads of other things like it blocks rendering it blocks interaction and I think it’s difficult for us to think in this way because as humans we are Extremely multi-threaded like I can stand here I can wave one hand I can stand on one leg I can wave the other leg and all the time I’m speaking I’m breathing and processing audio and visual information As humans we don’t really have a main thread. We don’t really have things that block unrelated things I mean we have one and That is when we sneeze Because as you begin to sneeze just stuff shuts down. You know like and the first thing you lose is the ability to talk Then you pull a stupid face If you’re driving at this point. This is where you think huh I hope no one dies Least of all me and then the human body becomes entirely single-threaded like you were sneezing Nothing else you can’t see hear think you can move and make noises but only in ways the sneeze wants you to you have no control over this at all and Then it’s over right you essentially wake up and You find out if your car is still on the road if you have the same number of limbs you started with the same number Of passengers you started with right needless to say we don’t want to write code that is like a sneeze So although we have this and this main thread thing we tend to spawn a whole series of threads like for networking stuff encoding and decoding crypto monitoring input devices But once these threads have done something that the page needs to hear about they need to sort of come back to the main thread to give it that information and It’s the event loop that orchestrates all of this they Take setTimeout for instance is it badly named? Yes. Are the arguments in the wrong order? I’d say so but have you thought about how it actually works? Well, let’s write a web standard for it because that’s what I do these days We’ll start with the setTimeout method, when invoked, must run the following steps: wait ms milliseconds invoke callback done But this isn’t quite working Because spec text like this this runs on the same thread as whatever invokes it and in this case it’s invoked by JavaScript, so this is running on the main thread so if we say wait 5,000 milliseconds we are waiting five thousand milliseconds on the main thread we’re blocking lots of other stuff, so This spec is very sneezy right now So we need to change that and we do this we run the steps in parallel which is magic spec speak for Get off the main thread or get off this thread and run this stuff kind of at the same time as other stuff but we create a new problem here because now we’re invoking a callback from something other than the main thread and I Mean, there’s no way this can really work You would end up with lots of JavaScript running in parallel still editing the same, DOM And you’d end up with all of these race conditions So what we do is this we queue a task and we queue a task to get back on to the main thread at some point And now we’re calling JavaScript on the thread where JavaScript lives, so it all works And this is a core part of how the browser works So if you click the mouse like how does that get from the operating system into your JavaScript? it queues a task When you fetch something how did you get the response into your JavaScript well? It queues a task and you send a message from a page to a worker once again it queues a task to do that So the first part the event loop I want to look at are task queues, and this is the oldest part of the event loop Rather than look at the spec I thought it might be easier to try and visualize the event loop so Here it is this is it. I hope that clears up any questions you have Actually, I really hope it does because I based the whole talk around this one diagram, so I hope it works But yeah without anything to do the event loop just spins round and round in a CPU efficient manner now This visualization is running at a fraction of a percent of real time And it’s still kind of too fast to really see what’s going on, so let’s slow things down a bit When we queue a task the event loop takes a detour so this here this detour here. This is where tasks happen So at some point the browser says to the event loop hey I’ve got a job for you to do and the event loop is like Excellent ok add it to my to-do list and I’ll get round to it at some point no problem done What if we do this like using set timeout we queue two callbacks That we want to run after one second 1,000 milliseconds well according to the spec we wrote these two algorithms Go parallel each waits for a thousand milliseconds And then they need to come back on to the main thread, and they do that by queuing a task So the browser says to the event loop hey, I’ve got something here that wants to do main thread work in fact I have two things and it adds each one as a separate to-do item in the task queue. The event loop’s like sure that’s Fine I’ll get round to it so it runs the first callback it goes around the event loop And runs the second callback And that’s tasks And it would be pretty simple if that’s all it was But it gets more complicated when we think about the render steps, and this is what the browser uses to update What’s actually on the screen The render steps are another detour and that involves style calculation. This is looking at all of the CSS That’s going on and working out what applies to each element Layout is in creating a render tree figuring out where everything is on the page And where it’s positioned And then creating actual pixel data. You know doing the actual painting So at some point the browser will say to the event loop hey, you know we need to wait to update What’s on the screen and the event loop’s like no problem, I’ll get round to that next time I go around the event loop now I don’t know about you, but I Would consider myself an expert at coding badly But I can take very simple bits of JavaScript and create infinite loops out of them in places I least expect, but let’s take a closer look at what happens when I do that Here’s a page with a gif and some text and a big button that runs an infinite JavaScript loop so if I click that button Everything stops the gif has stopped. I can no longer select text the whole tab has kind of come to a standstill Code for this are simple. This is just button click while true So how do we actually visualize this well the user clicks the button so the browser says Hey event loop. I’ve got a task for you event loop’s like yep. No problem. I’m on it But this task never ends, it’s running JavaScript forever a Couple of milliseconds later at the browser says hey event loop like um we need to update that gif that was on the page so if you could just Render at your next earliest convenience. That would be fantastic and event loop’s like yeah, okay? I’ll get round to that right after I finish this infinite loop that I’m busy doing right now Then the user tries to highlight text and that involves like hit testing Involves looking at the DOM to see what the text actually is so the browser says hey I’ve got a couple of more items For your to-do list there And the event loop’s like are you having a laugh like do you know how long it takes to perform an infinite loop? It’s a long time. You know. There is a clue in the name So that is why a while loop blocks rendering and other page interaction, but this is a good thing in practice We look again at the code that I started with I used to worry that this would result in a flash of content but it can’t right because this script runs as part of a task and That must run to completion before the browser can get back around to the render steps The event loop guarantees your task will complete before rendering next happens It still stresses me out though. I’ll always swap these lines around when I see it in code So a while loop blocks rendering, but what about this? So this is a loop, but each time we go round the loop we’re using setTimeout to queue the next call well, let’s find out so very similar testing before I click the button and Things are still working in fact. It kind of looks like nothing has changed, but in the background, here’s what’s happening We queue a task Go around the event loop Pick up that task and we queue another task as a result and that just keeps happening and happening until the end of time But as we’ve already seen like Only one task can be processed at a time So when it’s processed a task it’s having to go all the way around the event loop to pick up the next task So and that means at some point the browser can say huh we should update the display for that gif and it can it can Go around and update the display, and that’s why a setTimeout loop is not render blocking But if you want to run code that has anything to do with rendering A task is really the wrong place to do it because a task is on the opposite side of the world to all of the rendering Stuff as far as the event loop is concerned What we want to do is we want to run code in the render steps. I want to run code here And the browser lets us do that and it lets us do that using requestAnimationFrame Another another badly named function. I think but it’s it’s really good for this purpose RAF callbacks They happen as part of the render steps and to show why this is useful. I’m going to animate a box just just a box and Using this code, so I’m going to move that box forward one pixel and then use requestAnimationFrame to create a loop around this and That’s it that’s all it does so that’s requestAnimationFrame, but what if we switched requestAnimationFrame For setTimeout? It looks like this Now this box is moving faster It’s moving about 3.5 times faster, and that means this callback is being called more often, and that is not a good thing That’s not a good thing at all We saw earlier that the render rendering can happen in between tasks Yes, but just because it can happen doesn’t mean it must in reality. We can take a task shall we render No, it can’t be bothered yet. Go around the event loop pick up another task shall we render now now doesn’t feel like the right time many tasks can happen and Before the browser goes yeah actually next time we will update the display and The browser gets to decide when to do this and it tries to be as efficient as possible The render steps only happen if there’s something actually worth updating. If nothing’s changed. It won’t bother like If the browser tab is in the background if it isn’t visible it will never run the render steps because there’s there’s no point But also the majority of screens update at a set frequency in most cases That’s 60 times a second some screens Go faster some screens go slower But 60 Hertz is the most common so if we changed page Styles like a thousand times a second It’s not going to run the render steps a thousand times a second It will synchronize itself with the display and only render up to a frequency the display is capable of Usually 60 times a second, otherwise it would be a waste of time like there’s no point rendering stuff the user will never see But that’s what setTimeout is doing here It’s moving faster, because it’s updating the position of that box more times than the user can see more times than this display is capable of showing us also so far We’ve been using setTimeout as this kind of Shorthand for “queue a task” and it isn’t really because even though we’ve put zero milliseconds for the callback It’s more like four point Seven is what the browser will use as a default the spec says the browser can pick any number to use But in the things I’ve tested it seems to be about four point seven There isn’t a single method That just queues a task, but we can kind of fake it using message channels, and so I ran a test with that And if you’re sensitive to flashing images might be best to look away now because that looks like this The there’s so many tasks happening that it kind of just looks like the box is getting a random position We’re getting a task every two hundredths of a millisecond So rendering can happen between tasks, but you can have many even tens of thousands of tasks between renderings Okay, flashing image has gone now Let’s imagine each of these is a frame that is displayed to the user so our rendering steps They happen at the start of each frame and that includes like style calculation layout and paint not necessarily all three every time Depends what actually needs updating, but I like this I like this is very this is very neat and tidy this is this is a beautiful picture tasks on the other hand They couldn’t give a stuff. They just kind of appear anywhere they fancy. The event loop ensures that tasks appear They happen in the right order they happen in the order they were queued But in terms of timing within a frame. There is no kind of ordering here at all And we saw this with our setTimeout We were getting four per frame three or four per frame and that means that Three-quarters of those callbacks were wasted effort in terms of rendering old animation libraries used to do something like this Where they were trying to use a millisecond value that’s going to give them roughly 60 callbacks per second And they’re assuming a lot about the screen They’re they’re assuming a screen 60 Hertz, but that was the common case so it kind of worked it eliminated some of the duplicate effort Unfortunately it was a massive hack because setTimeout was not designed for animation And it really shows like due to inaccuracies you can end up with drift So what’s happened here is we’ve we’re doing nothing in one frame, and then in the next frame We’re doing twice the amount of work, and that is a visual jank to user it doesn’t look great Also, if one of your tasks runs long you can end up moving the render steps around because it’s all running on the same thread And you’re sort of disturbing there that lovely routine that they have if we use requestAnimationFrame Rather than setTimeout. It would look a lot more like this All neat and tidy all nice and ordered everything is within the timing of the frame even this longer task here When I see performance traces like this this makes me happy. This is showing a good user experience makes me feel very calm You can’t avoid tasks completely of course Because things like click events they’re going to be delivered to you in the task and generally you want to respond to those as soon As possible fair enough, but if you have things like timers or you have stuff coming from the network I really recommend using requestanimationframe To batch that work together especially if you already have animations running because you can save yourself a lot of duplicate work I treat tasks like I treat people who drink fizzy water Like I acknowledge that they exist But I keep our interaction to a minimum because I do not trust them at all I mean I would consider myself an empathetic person, but I have limits like I think soda water is Totally disgusting, and I cannot think of a way that a human being could drink fizzy water Without gagging or being sick or passing out or something so people when I say someone who does drink fizzy water? I think there must be something there must be something else going on with them I maintain a Twitter list of people who drink fizzy water It’s not a creepy thing I just I just wanna make sure I know what they’re up to and what they’re doing but when I find the link between these people and Brexit and Donald Trump. I am blowing the case wide open taking him straight to the FBI and it pains me to tell you this JSConf, but this conspiracy goes straight to the top I Saw him in airport drinking fizzy water Every now and then someone else a toons like over Jake you drink diet coke And I think you’ll find the main ingredient is fizzy water ha ha ha ha no that’s different That’s completely different like the main ingredient of air is nitrogen right? But you would still die if that’s all you breathed, so it’s more like that you cannot survive on just fizzy water What was I talking about? requestAnimationFrame, right There’s one more detail I want to get to and this is something that caught catches a lot of developers out it caught me out requestAnimationFrame it comes before processing CSS and before painting So code like this might seem expensive like we’re showing and hiding a box many many times, but this is actually really cheap like JavaScript will always run to completion before rendering happens So while you’re doing this the browser just sits back, and it lets you have your fun changing a value And it doesn’t really think about it in terms of CSS at all and then at the end When it actually comes around to the render steps it goes, right? What did you actually change in the end? And the only bit that matters is this final line And this explains a gotcha in CSS or at least something that caught me out I had a thing right, that I wanted to animate from an X position of 1000 to 500 And that sounds easy right so I had my listener here. I set the X position to 1000 I told it to transition and I changed the value to 500 But that animated from 0 to 500 and that’s like come on browser. That’s not What I asked you to do. It’s very clear I said 1000 transition to 500 what I was like I figured out that maybe I’m giving it too much information All at once And it’s the same reason we saw before like the browser is not going to think about it. Come just install one block of JavaScript So it’s going to ignore that first transform value So ok fair enough what I’ll do then is I’m going to put this second bit I’m gonna put inside a requestAnimationFrame and now It still animates from 0 to 500, and I was like. What is what is going on here well, I will tell you what’s going on because I finally figured it out the user clicks on the button and That’s a task so we come around to here and this is where we set the initial transform and the transition fine We queue an animation frame, and we go around and this is where we set the destination the final transform value But the browser doesn’t think about CSS until this next step over the purple block there This is where it calculates the CSS so again It totally misses the first value because it hasn’t thought about styles in between those two things being set And that’s why to make this work You need to use not one, but two requests animation frames and now this will animate from 1,000 to 500 Incidentally, there is a hacky alternative for this you can use something like getComputedStyle and just access one of the properties on it And this forces the browser to perform style calculation a lot earlier than it naturally would But it makes the browser take note of all of the things you set up until that point so it’s like oh, okay Transform translate X 1000 that’s a thing that this element does But you need to be careful with doing this because you can end up forcing the browser to do a lot of extra style work than it Really wants to it only really wants to do that once per frame In reality the best way to deal with this Would be the animation API the web animation API because you can just say I want it to go from here to this other Value and it all just works, but that’s only in Chrome, so it’s not really worth talking about right now So If the position if requestAnimationFrame within the render steps if that was a surprise to you if that was something you didn’t know already It’s probably not your fault. You might have been misled by particular implementations because Edge and Safari They get this very wrong they put RAF around about here most notably they put it after paint And that’s kind of annoying because it means like if the user clicks somewhere or something happens, and you want to batch that work You’ve been using requestAnimationFrame Edge and Safari they will render before they get to your callback so the user’s going to see something and that means that you’re not going to see the actual changes you make until the next frame along and that’s adding quite a significant delay to things appearing on the screen And it also makes it really difficult to batch work together. I hope this is something they fix soon Is there’s been activity on the bugs recently, but the web standards say it should be here, and that’s where it is in Firefox and Chrome Ok that’s enough about requestAnimationFrame. I want to take a look at microtasks this is probably the least understood part of the event loop I’d say I strongly associate Microtasks with promises, but this is not where they started back in the 1990s browsers wanted to give developers a way to monitor DOM changes And the w3c went okay, I’ll sort that out for you, and they gave us mutation events so this is where I could say okay I want to know when a node is inserted into the body element and fine excellent And you get a series of other events as well But in practice this was pretty problematic we take this bit of code here what I’m doing is I’m adding a hundred spans into the the body element How many events would you expect to receive as a result of this? one event? one event for the whole operation? nope 100 events one for each span yes But also another hundred for this line here when Content is going into the actual span a text node is going into the span and because these events bubble this simple piece of code Is going to land you with 200 events And because of this like relatively simple DOM modifications ended up triggering thousands of events and if you were doing like a tiny bit of work in these listeners that quickly became a Big bit of work, and it was a performance disaster What we really wanted was a way to sort of hear about a batch of this work It’s similar to what we saw with styles before we want the browser to kind of sit back Let us do some stuff and then at a convenient point say Some stuff changed it here is a kind of an event or something to represent all of those changes We want to hear about it once not 200 times and the answer became mutation observers, and they created a new queue called microtasks a lot of documentation I read about microtasks suggests that it happens like I don’t know every turn of the event loop or It happens after a task or something like that and that’s kind of true There is a single place on the event loop where micro tasks happen, but that is not where you’ll generally encounter it They also happen whenever JavaScript finishes executing yeah that means that the JavaScript stack has gone from having stuff in it to having no stuff in it and That’s where we run micro tasks So you can end up with microtasks happening halfway through a task you can have happen we can have micro tasks in the render steps as part of request animation frames kind of anywhere anywhere JavaScript can run So that means this JavaScript will run to completion Adding a hundred spans and their contents JavaScript finishes executing and we get our mutation observer callback Promise has made use of them as well so here we queue a micro task and then log yo JavaScript is finished executing So we go for the micro tasks, and we log hey And that means when the Promise callback is executing you were guaranteed that no other JavaScript is Midway through at the time the Promise callback is right at the bottom of the stack, and that’s why promises use micro tasks But what happens if we create a loop using micro tasks bit like we did with setTimeout before Same demo again click the button and It blocks rendering it blocks the tab in the same way a plain while loop did very different from setTimeout before So Promise callbacks are async fine, but what does async actually mean? I mean all it means is that they happen after Synchronously executing code, so that’s why we get yo before Hey But just being async doesn’t mean it must yield to rendering doesn’t mean it must yield to any particular part of the event loop We’ve looked at three different queues so far we looked at task queues animation callback queues which is where requestAnimationFrame callbacks happen and now we’re looking at micro tasks and Just to make your lives a little bit easier They all are processed very subtly differently Like we’ve seen with task queues we take one item and we take one item only and if another item is queued It just goes to the end of the queue fine animation callbacks they happen until completion Except ones that were queued while we were processing animation callbacks. They are deferred to the next frame Micro tasks on the other hand they are processed to completion including any Additionally queued items so if you were adding items to the queue as quickly as you’re processing them you are processing micro tasks forever The event loop cannot continue until that queue has completely emptied and that is why it blocks rendering Sorry, I get I get really excited about this stuff. I hope I hope other people are excited about this as I am Thanks. Thank you. Thanks one person excellent Do I used to have a real job right like many of you did? This stuff like that sort of speaking the standards work the creating slides. This used to be my hobby But then my hobby became my job, and now I have no hobbies I’m a boring person now, and I think didn’t I didn’t actually notice when this happened like Genuinely doing the first time. I noticed I went for an eye test and the optician just making small talk asked and And what are your hobbies? Oh shit When did this happen I don’t have any Like I said, I stress, so I I got a bit like oh, I can’t I can’t say nothing who says nothing so I totally true I panicked and I said I Play the piano I don’t play the piano And I stressed even more cuz I thought like she was going to say. Oh well. That’s great We don’t need to use the letters chart, then here’s some sheet music Can you read me the first five bars? What chord is this? Thankfully she didn’t but yeah my optician now thinks I’m a pianist that was great. I don’t go back to the optician’s anymore I’m terrified of like more piano chat. I don’t know how I survive in the real world Right I think you’re ready for this next one Occasionally I run little JavaScript quizzes. Maybe that’s my hobby. Nope that’s work too never mind. Yes I run little JavaScript quizzes, and this is my favorite question, so I’ve got a button an onclick I resolved a promise and then log something But I have two event listeners on the same element doing the same thing so if the user clicks a button What happens? In which order are things logged? Well our first listener executes great So that’s on the JavaScript stack Queues a micro task and then we get to the next line where we log Listener 1 and that’s the first answer Most folks agree on that bit but what next and I ran a Twitter poll on this last week I’ve been speaking to a few of you a few of you saw it Most people would say the next thing logged is Listener 2 that’s 63 percent 5% of people think NaN is just logged and then Infinity that is not the answer, but fair enough to that five percent of people, but yes, we’ve got 63 percent and Listener 2 is the wrong answer This is a real gotcha with script, but if you thought it was Listener 2 then you’re in very good company, so don’t worry about it Our listener has finished, so we’ve gone from having something on the JavaScript stack to nothing So it is micro task time we are going to run that promise and we are going to log Microtask 1 and there we go and Then it’s time for the second listener and that works the same so the order is Listener 1 Microtask 1 Listener 2 Microtask 2 But that’s if the user clicks the button what if the button is clicked using javascript. Oh, yes, it’s different For starters our script is on the stack. We call click and that synchronously Dispatches the events so we start with listener one great We queue a microtask and we log listener one and now it’s microtask time no No, it is not microtask time. We can’t run microtasks This is where it’s different because our JavaScript stack is not empty button dot click has not returned yet So we move on to Listener 2 we queue another microtask and now we log Listener 2 and this is where it diverges And now our listener is done in fact all our listeners are done Button dot click returns, our JavaScript stack empties and now we can process those microtasks And they happen in order and this has real-world implications they so beware if you’re using like promises in this way, you’re using if you’re using automated tests as well because Automated tests if they’re clicking things on the page They’re likely to be using javascript to do it and that can change the behavior of your code This also came up when we were looking at how to add Observables to the DOM and how they’d integrate with promises we hit this question If we have a promise that represents the the next click of a particular link. It’s just this little bit of code here Can someone use that promise and still call event dot preventDefault? promises are async So have we missed our chance to prevent the default here? Turns out no, It’s fine. It’s totally fine this works This just works unless again The user clicks the link er some code clicks the link using javascript And this is the final puzzle of the talk I’m overrunning a little bit to figure this out We actually need to take a look at the spec So this is a very rough description of how the spec for clicking a link works but we start by creating an event object and then for every listener we have we invoke that listener with the event object and Then we take a look at has that event object’s canceled flag been Set if it’s been set then we’re not going to follow the hyperlink But if it’s unset we will follow the hyperlink when you call event dot preventDefault it sets this canceled flag on the event object So if the user clicks a link that’s fine our micro tasks happen here after each callback because that’s where the JavaScript stack empties But when we call click with JavaScript. It’s just going to call out to our process a link click Algorithm, and it only returns once that algorithm is complete so the JavaScript stack never empties During this algorithm so our micro tasks can’t happen so it hits this step three where it looks at the event object and Even if you’ve got loads of promises trying to call like preventDefault It’s too late. It’s going to follow the hyperlink and then sometime later those promise callbacks happen, but you’ve missed the boat You’ve missed a point where you can actually cancel that event so Remember that micro tasks they you know they behave quite differently depending on the JavaScript stack Ok so that 34 minutes that was a massive brain dump of everything I know about the event loop and the various steps and various queues. I have found that knowing this stuff Like it prevents that case where you kind of got a bit of code That’s not doing what you want So you just wrap it in a setTimeout and now it kind of works sometimes Knowing the stuff kind of helps avoid that it helps me avoid jank by getting stuff running on the correct part of the event loop As well, and I hope I managed to explain this stuff in a way that is helpful to you too, like I said I’m a stressful person so as a result of this I’m now going to go and collapse in a pile, but you’ve been a great audience. Thank you very much cheers

Jake Archibald: In The Loop – JSConf.Asia
Tagged on:                             

100 thoughts on “Jake Archibald: In The Loop – JSConf.Asia

  • March 2, 2018 at 7:46 pm
    Permalink

    Just like always, amazing presentation, especially when you magically swapped those lines around at 2:25 ๐Ÿ˜ฒ

    Reply
  • March 2, 2018 at 7:48 pm
    Permalink

    Is he using a Nintendo Switch Joy Con to control his presentation?

    Reply
  • March 4, 2018 at 12:11 pm
    Permalink

    Love the main thread animation.โ˜บ๏ธ

    Reply
  • March 7, 2018 at 3:26 am
    Permalink

    Excelent talk!

    Reply
  • March 7, 2018 at 3:54 am
    Permalink

    Great presentation with an interesting reference to music, yet Web Audio timing got eluded from the loop ๐Ÿ™‚

    Reply
  • March 8, 2018 at 8:41 pm
    Permalink

    Love Jake's talks, always super solid, informative and even include some giggles from time to time!

    Reply
  • March 12, 2018 at 7:24 pm
    Permalink

    The jokes were hilarious and were even funnier because the audience was so painfully silent. Without a doubt, it made the talk better and made me like you more. I'm guessing there was some sort of language barrier there with the audience.

    Reply
  • March 13, 2018 at 3:53 pm
    Permalink

    Great video – however your test actually varies from Chrome to Firefox – I believe Firefox is listener 1, listener2, microtask 1, microtask 2, and chrome is the way you state it. see for yourself https://jsfiddle.net/mande79m/5/

    Reply
  • March 22, 2018 at 1:23 am
    Permalink

    Great talk!

    Reply
  • March 29, 2018 at 1:45 pm
    Permalink

    Are the arguments of setTimeout in the wrong order? Actually there is an argument made by Douglas Crockford suggesting that it is in the right order: "…callback argument should be first. And the reason is we can now have functions with a variable number of arguments using the ellipsis operator. The ellipsis has to come at the end. So, it means the callback has to be first." (https://youtu.be/NPB34lDZj3E?t=21m35s)

    Reply
  • April 7, 2018 at 1:55 am
    Permalink

    I was testing the cat gif while loop page Jake did the demo of : http://event-loop-tests.glitch.me/while-true-test.html
    But I am unable to see the GIF being stopped. For me in Chrome the GIF seems to play fine even after clicking the button.

    Edit: In Safari the GIF will stop

    Reply
  • May 2, 2018 at 2:11 am
    Permalink

    Well, looks like Surma is also a soda water drinker, looks like he cannot trust him either…

    Reply
  • May 6, 2018 at 5:35 pm
    Permalink

    Refer to this article to understand microtask queue. It has good animated stuff which might help: https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

    Reply
  • June 12, 2018 at 3:05 am
    Permalink

    awesome talk!

    Reply
  • June 14, 2018 at 8:16 am
    Permalink

    He really hit the core of the event loop. Something that is so important to get hold of tasks, micro tasks.

    Reply
  • June 25, 2018 at 8:42 am
    Permalink

    This is GREAT.

    Reply
  • July 9, 2018 at 10:21 am
    Permalink

    Oh my gosh, that's very simple, clear and informative. Great speaker, great presentation.

    Reply
  • July 28, 2018 at 2:02 pm
    Permalink

    Wow, that presentation was just awesome, perfect, splendit!

    Reply
  • August 9, 2018 at 12:31 pm
    Permalink

    I feel like I just watched epic blockbuster with huge budget, Tom Cruise and stuff

    Reply
  • August 18, 2018 at 7:54 am
    Permalink

    Thanks for such an amazing talk !!

    At 32:01, Did not understand how the listener 2 can execute while the stack is not empty ? The callbacks in the tasks queue run only when the JS stack is empty right ?

    Reply
  • August 21, 2018 at 8:08 pm
    Permalink

    Great talk, watched several times. I'm wondering if anyone else has had trouble recreating the cat gif animation stop because of blocking code. Simple event listener with while true evaluating inside of it. But it doesn't seem to pause the gif I have in my html

    Reply
  • September 8, 2018 at 9:21 am
    Permalink

    I don't not understand why he is stressed by the fact that someone is holding a Mac with 2 fingers…

    Reply
  • October 17, 2018 at 12:12 am
    Permalink

    That laughter at the end "back to the studio" ๐Ÿ˜€

    Reply
  • October 18, 2018 at 7:57 pm
    Permalink

    The Edge + Safari thing you said at 23:30 , I've been trying to fix a bug with something flickering only in edge/safari, thanks ๐Ÿ˜›

    Reply
  • October 25, 2018 at 2:49 pm
    Permalink

    This talk is soooo informative. A single effective visual plus narrative beats a thousand words.
    Could someone enlighten me of the tool or the way for the speaker to make the slides (or something else) ?

    Reply
  • October 30, 2018 at 9:34 am
    Permalink

    I wish I learnt all my CS courses from you Jake.

    Reply
  • November 5, 2018 at 5:54 pm
    Permalink

    Really love this video

    Reply
  • November 6, 2018 at 5:43 pm
    Permalink

    This is awesome! I had developed a parallax feature using rAF, and I was wondering why it was smooth on Chrome but janky on Edge, this explains it ๐Ÿ™‚

    Reply
  • November 19, 2018 at 11:03 am
    Permalink

    31:29 So how can we reliably simulate user interactions with or without JS? Are there any standard approaches for testing such cases?

    Reply
  • November 26, 2018 at 1:42 am
    Permalink

    I'm confused – according to the video, any visual changes happen after a js script was finished. But how does this work – you can simply add an element to the DOM and then change it's text and then simply measure it using simple synchronous js script. Without waiting for a re-rendering. This broke my head… – https://stackoverflow.com/questions/118241/calculate-text-width-with-javascript/5047712#5047712.

    Reply
  • November 26, 2018 at 1:11 pm
    Permalink

    ๐Ÿ™‚

    Reply
  • December 5, 2018 at 11:47 am
    Permalink

    cool

    Reply
  • December 26, 2018 at 2:27 am
    Permalink

    He would be beyond perfect if he can slow down like 2x

    Reply
  • December 27, 2018 at 12:08 pm
    Permalink

    This is presentation was insanely good. Great job Jake!.

    btw, what software was use to create this presentation?

    Reply
  • December 30, 2018 at 10:16 pm
    Permalink

    Thank you!

    Reply
  • January 20, 2019 at 8:05 pm
    Permalink

    Great job

    Reply
  • January 22, 2019 at 5:26 pm
    Permalink

    Super great explainer, whoever did the design for the animations deserves a massive shout-out. Well thought out and great visual metaphors too.

    Reply
  • January 31, 2019 at 2:56 am
    Permalink

    It's very informative. Thanks Jake.

    Reply
  • February 3, 2019 at 3:00 am
    Permalink

    cool visualization

    Reply
  • February 11, 2019 at 10:04 am
    Permalink

    Example at 22:13 with 2 requestAnimationFrame doesn't work for me, neither did getComputedStyled(box). Anyone had this problem? Tested on chrome 71.0.3578.98

    Reply
  • February 20, 2019 at 5:26 am
    Permalink

    Amazing talk! I love the little laugh at the end of the presentation

    Reply
  • February 21, 2019 at 5:45 pm
    Permalink

    wow that was really great talk, i did know that microtasks existed but didn't know when it was executed. Also about the difference between .click() and a user click, shouldn't we have a JS way to make it exactly like users click or dispatching an event click works?

    As always your job was amazing, but gosh, it was a bit sad not hearing the crowd

    Reply
  • February 27, 2019 at 11:04 pm
    Permalink

    What a great feeling, just learned awesome stuff. Thanks!

    Reply
  • March 5, 2019 at 1:28 pm
    Permalink

    Now this is what you call a talk. Impeccable ๐Ÿ‘Œ

    Reply
  • March 8, 2019 at 2:29 pm
    Permalink

    Humans are single threaded when they sneeze…that's hilarious

    Reply
  • March 11, 2019 at 4:31 pm
    Permalink

    His delivery reminds me of Ricky Gervais soooooooo much, except for the cussing and the beer ๐Ÿ˜›

    Reply
  • March 14, 2019 at 5:51 am
    Permalink

    What about DOM access which triggers layout? Doesn't it run the critical rendering path immediately?

    Reply
  • March 19, 2019 at 4:10 pm
    Permalink

    awesome explanation sir great, really love to listen you

    Reply
  • March 23, 2019 at 11:16 am
    Permalink

    Wow! That is one of the most informative talks I ever heard.

    Reply
  • March 23, 2019 at 6:51 pm
    Permalink

    I think I'm just gonna master JavaScript/TypeScript, Vue.js for now. As a developer, I personally think depth is much more important than breadth.

    Reply
  • March 24, 2019 at 2:23 pm
    Permalink

    3 times watched to understand this boss and still going.

    Reply
  • April 2, 2019 at 7:50 pm
    Permalink

    25:00
    I had this workaround pop into mind:
    function onNodeInsert() {
    elem.removeEventListener("DOMNodeInserted", onNodeInsert);
    requestAnimationFrame(() => elem.addEventListener("DOMNodeInserted", onNodeInsert));
    console.log("DOM Node inserted !");
    }

    Reply
  • April 5, 2019 at 6:36 am
    Permalink

    Most informative and engaging talks on event loops! Kudos Jakes.

    Reply
  • April 12, 2019 at 1:45 pm
    Permalink

    2:55 "there's no promises there", is that pun intended?

    Reply
  • April 17, 2019 at 2:09 am
    Permalink

    I learned a lot about the event loop from this. Very good explanation. On a side note: I too have a slight distrust of those who claim to like soda water. I don't get it and my mouth finds it very offensive.

    Reply
  • April 22, 2019 at 6:49 am
    Permalink

    Amazing presentation! I loved the visuals and the concise explanations. Does anyone know the presentation software used? It would be pretty impressive if that was a PowerPoint slide deck.

    Reply
  • April 27, 2019 at 8:44 am
    Permalink

    This is such a tough audience, this guy is hilarious to me๐Ÿ˜‚๐Ÿ˜‚๐Ÿ˜‚

    Reply
  • May 5, 2019 at 9:44 am
    Permalink

    You can have a new hobby at which you are extremely good and it's technical presentations about JS and web.

    Aaaa, also, the how different queues are processed made shivers run up my neck. Really excited. Wife (who is senior QA) is getting jealous of you :p

    Reply
  • May 13, 2019 at 10:39 pm
    Permalink

    The piano chat part is totally relatable. When i do a talk in front of thousands of people I want to be as funny as this man

    Reply
  • May 14, 2019 at 3:38 pm
    Permalink

    Why the F isn't this video watched 1 million times? This is amazingly informative and presented in a really really good way ๐Ÿ™‚

    Reply
  • May 18, 2019 at 6:13 am
    Permalink

    Excellent explanation ๐Ÿ‘Œ

    Reply
  • May 28, 2019 at 6:14 am
    Permalink

    Amazing talk. Cleared my concepts. Good Job !

    Reply
  • May 28, 2019 at 7:40 am
    Permalink

    The difference after adding 2 requestAnimateFrame() is not visible, can anyone share working code please

    Reply
  • May 31, 2019 at 1:29 am
    Permalink

    sw33t!

    Reply
  • June 1, 2019 at 9:39 pm
    Permalink

    Who else is here because of Fireship?

    Reply
  • June 2, 2019 at 10:55 am
    Permalink

    very cool explanation! It is very sad that I couldn't give you 100 likes

    Reply
  • June 2, 2019 at 2:55 pm
    Permalink

    I feel like I just started learning this stuff and I've been doing it for so long. Amazing!

    Reply
  • June 3, 2019 at 9:44 am
    Permalink

    Great talk! Amazing animations too ๐Ÿ˜€

    Reply
  • June 8, 2019 at 10:11 pm
    Permalink

    Didn't know anything about this. Now I feel like wanting to dig more into JavaScript

    Reply
  • June 10, 2019 at 11:55 pm
    Permalink

    Remarkable illustration. Could you share what tools you used to generate the animation?

    Reply
  • June 21, 2019 at 5:26 am
    Permalink

    lol…i should give my next talk just wearing socks

    Reply
  • June 21, 2019 at 4:46 pm
    Permalink

    Jeff Delaney brought me here

    Reply
  • June 21, 2019 at 9:04 pm
    Permalink

    What an excellent talk!!

    Reply
  • June 23, 2019 at 2:10 am
    Permalink

    I only drink fizzy water if available.

    Reply
  • June 24, 2019 at 8:07 am
    Permalink

    Something just confused me on the diagram. I tried doing 2 AJAX requests, one which takes 5 secs to respond and 1 which takes 1 sec. However I can make multiple requests while the 5 second one is still processing. How come it seemed like it wasn't queued at all?

    Reply
  • June 25, 2019 at 6:05 am
    Permalink

    clear and simple explanation for a beginner to get a grasp of what is going on under the hood, well done! Correct if I'm wrong but I think there is a mistake in the little exercise at 30:32 . It should be promise.then('Microtask 1') instead of promise.then('Listener 1') and same for number 2.

    Reply
  • June 26, 2019 at 4:15 am
    Permalink

    When you want to be a stand up comedian and life makes you a JS expert

    Reply
  • June 26, 2019 at 9:51 pm
    Permalink

    Jake, where are your sneakers?

    Reply
  • June 28, 2019 at 8:15 am
    Permalink

    One of the best talks of all JSConf

    Reply
  • June 29, 2019 at 5:12 pm
    Permalink

    Now that was a fucking insane talk. Whoa! Blew my socks off!

    Reply
  • June 29, 2019 at 6:44 pm
    Permalink

    Very nice video, TNX

    Reply
  • June 29, 2019 at 11:21 pm
    Permalink

    But did he use Powerpoint?

    Reply
  • July 8, 2019 at 12:49 am
    Permalink

    is he wearing socks???

    Reply
  • July 8, 2019 at 10:55 am
    Permalink

    @4:08 Human beings are just like JavaScript, single-threaded and event loop(ed)!
    Yes, that is correct. Human beings are not multi-threaded. Even when we see from two eyes, we are not seeing it thru two eyes simultaneously, we see from one eye once and then from the second eye, and the same goes with all senses.
    (To prove it: And that is how the 3-D glasses work, they work on more than 200Hz refresh rate of TV panels where the 3-D glass switch between 2 lenses in 100Hz frequency) and this is how you see 3-D happening!

    Reply
  • July 8, 2019 at 5:22 pm
    Permalink

    Some impressive moments

    Reply
  • July 14, 2019 at 6:17 pm
    Permalink

    I've long wanted to name the entity that selected threads then instructions. Within a thread it is an instruction pointer. I was thinking to call them 'Gremlin'. Wish JS would give us more than one Gremlin. Though seeing your diagrams perhaps 'Pacman' would be better than either a square box or a Gremlin.

    Reply
  • July 15, 2019 at 9:24 pm
    Permalink

    Came here to learn about event loops.

    I now fear those who drink fizzy water.

    Reply
  • July 17, 2019 at 1:08 pm
    Permalink

    INCREDIBLE presentation. Absolutely incredible animations! Thanks so much for posting this! ๐Ÿ˜€

    Reply
  • July 20, 2019 at 2:28 am
    Permalink

    big up semi colons !!

    Reply
  • July 21, 2019 at 3:57 am
    Permalink

    Finally, a JS expert with a sense of humor !

    Reply
  • July 27, 2019 at 9:01 am
    Permalink

    Great explanation, thank you.

    Reply
  • July 27, 2019 at 10:59 am
    Permalink

    Just as you started talking about sneezes I sneezed. WHY??????

    Reply
  • July 29, 2019 at 7:53 pm
    Permalink

    22:22 I got why it dint work earlier, but why does raf within raf work correctly though?

    Reply
  • July 30, 2019 at 2:51 am
    Permalink

    Who upload the chinese subtitle? too naughty ๐Ÿ˜„.

    Reply
  • July 31, 2019 at 11:39 am
    Permalink

    I was that guy who would throw in a setTimeout and play around with the delay number until the manual test matched the automated test.
    It would raise an eyebrow at code reviews, but I'm a pragmatist not a purist.
    Now I know why I was right! Thanks Jake.

    Reply
  • August 4, 2019 at 8:15 am
    Permalink

    I love how it feels like he's going on completely unrelated tangents but it always seemlessly transitions back into the main idea

    Reply
  • August 13, 2019 at 6:48 am
    Permalink

    This is one of the best talks I have seen after Phillips Roberts What the heck is the event loop? Both these talks helped me understand the Event Loop and get better context
    I then took the JS the Hard Parts from Front End Masters by Will Sentence. It was great. I got a better understanding of the the async and concurrency model of JS

    Reply
  • August 14, 2019 at 9:54 pm
    Permalink

    Who is here because of Fireship?

    Reply
  • August 20, 2019 at 3:24 am
    Permalink

    This is awesome!. One question, what about observables and subscriptions?. Are there on the task or microtasks queue?

    Reply
  • August 30, 2019 at 4:57 am
    Permalink

    This is a wonderful talk! A very illustrative and beautiful explanation of the javascript's internals. Do any of you know a talk about the internals of other languages like this ? Java? Python? PHP ?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *