JavaScript Concurrency and the DOM - Kristofer Baxter and Malte Ubl - JSConf US 2018

[Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] [Music] [Applause] well great hello everyone I'm Christopher Baxter and I'm multiple we're going to talk about concurrency in JavaScript with a particular focus on the Dom now

concurrency is a big topic it's maybe a complicated topic so let's look at some of the basics behind it currency is really it's just a technical word for multiple parts of a computer program running at the same time now if your computer or phone has more than one core which it does or you have more than one computer which the cloud does then this can make things get done much faster however it generally also makes things

way more complicated speaking of concurrency you always kind of have to talk about like the difference between parallelism and concurrency they're just the same thing but someone in the 80s took away the awesome word which is parallelism and made it means something very specific but that doesn't matter are we gonna say parallelism and concurrency interchangeable who cares so another important concept are threats they're just programs that run on a computer and there can be more than one threat active

at any given time now concurrency doesn't require multiple threats for example network requests can happen while your main thread is running and so that's still a concurrent program but if you have only one thread and your program can only do one thing at a time on a given device so we saw call such a program single threaded and that's an important term because web browsers which we're talking about today are traditionally

single threaded now today they're like these complicated beasts and they do many things at the same time but they very much still behave as if there were a single threaded so it's a good model to have in your head the single thread we call the main thread and very important is this Jess confit your JavaScript runs on the main threat by default so if you write some JavaScript and it's still running your browser cannot do anything at the same time which might be bad because oh my god we have to achieve 60 frames per

second all the time where does his number come from that's basically the fundamental constant of runtime performance it's how often on a normal device your graphics card would like to push pixels to the screen now humans don't you know bias to this particular framework frame rate for example movies traditionally run in the 24 frames per second important is that they always run 24 frames per second humans are really good at recognizing changes in frame rate if

frame rate isn't stable we call that Jack and jank is really bad because it makes our you know brains go wild now 60 frames per second leads to another magic number which is 60 milliseconds that's just 1,000 milliseconds in a second divided by 60 which is what do you have to update the screen right well unfortunately it's more complicated so there's you and then there is stuff the browser does which is a layout style

calculation painting compositing actually physically flipping the pixels on the screen and everything in that 60 milliseconds has to fit into that kind of budget great so let's break that down a little bit because it's pretty darn complicated you've got 16 milliseconds a lot of code to execute and you're trying to get it all done within this time frame the important thing to remember though is that's not just your code your code runs for a certain amount of time and the browser needs to respond to the changes that you asked it to do as well