This course has been updated! We now recommend you take the Build Progressive Web Apps (PWAs) from Scratch course.
Transcript from the "Introducing Web Workers" Lesson
[00:00:00]
>> Mike North: Now that we've had a little refresher on promises, we're going to put them to work in combination with something that is really powerful idea, right? It's been around since i11, but it is widely underutilized. So if promises are overutilized and you see promises everywhere, even in places where it is potentially not necessary to use them.
[00:00:27] This is, JavaScript workers are something that could probably ease a lot of pain in apps. And people are, to some degree, either afraid or not knowledgeable enough to figure out a way to make this idea work for them. And here is the general idea. So JavaScript, the way it works internally, you can think of it like a single really awesome multitasker.
[00:00:55] So JavaScript has a great concurrency story, but it is one thread that your program is running on. And although we can send out 15 Ajax requests, and they're all happening, the browser is kind of taking that ask for some data at this URL and running with it, and something's happening.
[00:01:15] You can think of that as almost like, I've set an alarm, I've set a timer and it's gonna go off in a couple minutes. Or I've,
>> Mike North: Ordered something on the phone and it'll come later. But at any given time, you're only one person kicking off all of these things and then handling them when they complete.
[00:01:35] When we talk about parallel programming, this is the idea, this is like two multitaskers doing things at the exact same time in the same moment. That is the power of JavaScript workers. So when we create a worker, yes?
>> Speaker 2: Two or n, like?
>> Mike North: n.
>> Speaker 2: Okay.
>> Mike North: When you solve the problem and you can get two, you can get N.
[00:01:59] So moving from one to two is the big idea here, or one to n, as you readily point out. So we basically create a worker using this worker constructor you see here, right? And the single argument that we pass to it is the path where a script can be found, and this could be a URL, the script could be it is yet to be downloaded.
[00:02:23] But it is sort of a self-contained world in it and of itself. And this is good because you want to have sort of pretty rigid walls in between these different things that are running. For example, you can't really share scope in between these without going through a little explicit passing of information back and forth.
[00:02:44] When you create a worker, you can send messages to it, and that worker can send messages back to whatever created it. And in this case, we're talking about a dedicated worker. We will add some nuance to the problem in a moment. So this is what your application would look like if you're creating a worker.
[00:03:02] Now, if we take a look at what might happen inside worker JS, on the right side of the screen, for completeness, that first line is just, we're getting a log function that is doing our console logging. So I've made this a complete example, but that's not meaningful here.
[00:03:21] And you can see that we have a self.onmessage that we're defining, and we set the value of onmessage to a function. And this function will be called whenever the host application sends something to the worker via postMessage. So we send it an object and it's going to retrieve.
[00:03:40] So the onmessage function will be called with an event, just like if you've ever hooked up to an input, an HTML input, you can usually find that there's this event that represents some additional meta information. And on that event, you can usually find the data of interest, something that has changed.
[00:04:02] So in this case, you'll get a single argument in onmessage, and you'll just gonna wanna pluck the data attribute off of that, and you'll get that object. And we're gonna console log fit like, as the worker, I have received this data, and in Chrome and in modern browsers, this will be mixed together with your host applications log.
[00:04:23] You'll see it all there together. You may see a little gear next to it, and that represents that this came from a worker. I will demonstrate how this works as we spin up to the first exercise here. So then within this worker, we're going to kick off this function doWork.
[00:04:46] And the important thing I want you to see is that we're using setTimeout, which is available to us inside the scope of this worker. And in two seconds, we're gonna take the string that we were passed, and we're gonna uppercase it, and then we're gonna send it back to the parent.
[00:05:04] And the parent is going to receive it on the onmessage function here. So this is a little clunky, we wish that this was written with a promise-based API or even a true callback-based API. And you can see here, we are assigning function values to special property names, this seems very old to do it this way.
[00:05:29] And the reason is the standard was invented in 2010, 2009, and promises were a thing, it was like a jQuery feature or a Dojo feature, and it was not part of the standard. So it's not all that refined, but it is still really powerful idea here. And the power here has to do with the fact that although computers are getting faster year over year, if you've ever heard of this concept of Moore's law.
[00:06:01] It basically says like, over time, the number of semiconductors we can pack into a chip, I believe it doubles every seven years. The problem now is we're getting 10, 12 cores, the new Mac Pros, they have 18 cores on them, and JavaScript can only run on one of those at any given time.
[00:06:22] Your application is running on one-eighteenth of that processor. And the ability to put things onto other cores is an important way that JavaScript can kind of step forward, and then we can take advantage of these advancements. So we're sort of scaling horizontally at this point and not vertically.
[00:06:40] And it's really important that, as a programming language, to stay relevant, we learn to take advantage of all that unused capacity.