A Comparison of Web Workers

Hi, I'm Thomas Hunter and this talk is a comparison of web workers. The content from this talk is adapted from a book I recently published, Multithreaded JavaScript. If you'd like more about the book, feel free to follow that bitly URL at the bottom of the screen.

All right. So today we're going to talk about three separate topics. The first one is dedicated workers. The second is shared workers. And the third is service workers. Each one of these workers is a type of web worker.

But first, I'm actually going to talk about some basics. So, first, the concept of multithreading JavaScript. One thing to keep in mind is that it is the nature of JavaScript and its ecosystem to be single threaded. So for the longest time, there really existed no true multithreading capabilities in JavaScript. You can sort of pull some of this off by using basic message passing, using iframes. But it wasn't exactly the cleanest solution. However, now we have web workers available to us. And with that comes a feature called shared memory, which allows for higher performance and multi threading than just using message passing. This presentation is going to be from the perspective of using these web workers from a multi threading purpose since it is sort of related to the book.

All right. So another basic concept is, well, what is a JavaScript environment? Well, a JavaScript environment is an isolated collection of variables, globals, things like, you know, capital O object are going to be different in these separate environments, the prototype chains, you know, what those objects end up pointing to are different in these different environments. Each one each additional environment is going to incur some overhead to spin up and so with Node it's easier to measure. In my experiments it was about each new work of thread instance consumes about six megabytes of memory. In a browser you're going to get some more overhead. Web workers will incur some additional memory overhead and then if you have additional pages there's even more overhead as there's different documents and rectangles that need to be rendered.

So, these object instances that are created in these different environments, they can never truly be shared across environment. However, you can serialize these objects, you can sort of clone them, or you can represent them as JSON and then pass them around between the separate environments. However, if you mutate one in one place, you're not mutating it in the other. None of the web workers that we're going to look at today have access to the DOM. So, for example, the document object global is not available within the web workers. Using the shared array buffer, if you pass one of those between these different environments, a pointer to this the same binary data in memory will end up getting shared and that's how we can perform shared memory data access.

And a lot of this explanation is short of hand waving over some complexities under hood with relation to context and realms and really how the JavaScript VM works.

All right. So, now let's take a look at dedicated workers. What is a dedicated worker? Well, a dedicated worker is the simplest of the web workers that we're going to look at. Each one of these dedicated workers can have exactly one parent. You can actually end up loading them as a hierarchy if you want where dedicated workers can load other dedicated workers as well. And each one of these workers gives us a new JavaScript environment. Each one is also able to execute on a separate thread.

So, now, let's look at a code sample. This is how we would work with a dedicated worker from the context of the web page. So, maybe this sits in, like, an index.html file. Maybe it sits inside main.js loaded by an HTML file. But at any rate, this runs within the main thread that draws the window. And so, modern browsers give us a capital W, worker global. We're able to instantiate that to create an instance of a worker. The argument to this is the path to a file we want to use is the worker. Once we get the worker, we can attach a message handler on it. Here I'm assigning this dot on message handler, which is a callback function. When this function gets called, it's going to print the message from worker and then print the data that was passed into it. This code will get called within the parent thread when the dedicated worker thread has passed a message to it. And then conversely, if we want to pass a message into the worker, we call worker.postmessage where we pass in an argument. I'm passing in a string, but we could pass other simple values as well or basic objects with a few caveats. And then finally, at the end of the file, we're just logging that the end of the main.js file has run.

So now let's look at the dedicated worker inside the worker. So this is our worker.js file that was referenced in the previous slide. So in this file, the first thing we do is we just log that we're inside the worker. And then we assign a global on message handler, which accepts the message that was passed in from the parent. And so within this handler, we'd log a message that we received a message from main, we log the data that was passed into us. At this point in time within an application, this might be a good place to perform a heavy CPU, CPU heavy calculation. And then finally, we can call the postMessageGlobal to post a message back to the parent.

So let's actually execute the code and look at the output. Here I've already executed it for us. So the first thing we see is we see the message Hello from Main. And then even though we pass the message into the child, we end up logging the message Hello from the end of Main. So a non-deterministic amount of time sort of passes before the message is actually received by the worker and processed. So within there we print hello from worker, and then we print from Main message to worker. And then finally, the message that was passed back to the parent thread is then printed as well. So from worker, message from worker, that's the final message there.

And so why might you want to use a dedicated worker? Well, the most important reason in my opinion is that it gives access to an additional thread. And so this is a great way to offload CPU-intensive work or things that might otherwise slow down a web browser. Things that might cause scroll jank, you're able to offload this additional thread. And so you pass the message to the thread then the main thread is able to perform other work. And then once it receives a message back from that dedicated worker, it's then able to handle that value and then sort of continue with what it's doing. One thing to keep in mind is that a dedicated worker, anytime its single parent dies, that dedicated worker will die as well.

And next up, we're going to look at shared workers. What is a shared worker? Well, a shared worker it's actually pretty similar, but it can actually have multiple parents. And so it's useful for communicating across different windows. There's a caveat that these windows need to be on the same origin. So for example, you can't have the Google web page communicating with the Microsoft web page. They have to follow the same origin rules. So let's again, look at some sample code. And so first we're going to look at the code that might run within like an HTML page. And so we can pretend that we have two different HTML pages. Both of them have a script. One is the red HTML and the other is the blue HTML. And so within these files, we have like a script tag that's instantiating a shared worker. So the shared worker is available again in modern browsers with a small caveat that I'll cover at the end. So much like the other workers, we instantiate the shared worker and we pass an argument, which is a path to the file, to be used as the worker file. However, the API to interact with it is slightly different where instead of assigning an onMessage property directly on the worker, we assign it to a port. And so that port property represents a communication port into the worker itself.

And so the interface otherwise, this is fairly similar to the dedicated worker where it's a callback that will take an event argument with a data property that's passed into it. In this case, we're just logging a message that says we received an event. And then so later what we'll want to do is pass a message into the shared worker from one of the HTML files. And so to do that, we would call worker.port.postMessage, passing in the message that we want to pass into it.

All right. So here's some code on how to use the shared worker from the perspective of the worker. So this is our shared worker JavaScript file. Now, there's a bit of complexity going on in here. And I'll try to sort of explain everything step-by-step. But really, the purpose of this is just to sort of show how the shared worker works. So the first thing I do in the shared worker is I generate an ID. So that number, it's just a big random number to sort of show that this code is only going to be executed once. And so the next thing we do is we just print a log message that we're inside the shared.js file and we log that ID again. Next up, we're creating a variable called ports. And that's a set, and that's going to contain the ports that are passed into it. After that, we have an on connect method that's assigned to the self. And so what this is, this is a callback that gets called every time a different webpage makes a connection to the shared worker. So if you've ever worked with web sockets, this code pattern might feel a little familiar. So the first thing we do is we extract the port from the connection, and then we add it to our ports set. And then we just log that a connection has been made. We're just logging the the ID again and then also the size of the ports, which is going to tell us how many pages are connected.

After that, we signed an on message handler to the port itself, and that's saying that when this port receives a message. So when one of the HTML pages sends a message into this shared worker, we want to be able to handle it here. So again, we'd slog into the message, we'd say that the message was received, the ID in the data was passed in. Now, previously with the dedicated worker, when we wanted to send a message back out to the parent, it was pretty straightforward. There was a single port and we would just post the message to it. However, with shared workers, since we can have more than one parent, that's why we're sticking each one of the ports into the ports set, and then we're iterating over them here, and then we're calling the post message on each of them. Now, post message, it only allows us to send a single value through it. However, in this case, I'm just sort of abusing an array to pass the ID and the data that was received as well. And so let's say that we actually go ahead and execute this code on our machine.

So maybe the first thing we do is we open the red.html file. And so what happens, we're going to see that the shared.js file is executed. And we see that an ID was generated. That ID is 1, 2, 3, 4, 5, 6. And then we see that a connection is made. And the red.html has connected to the shared worker. And again, we print that ID. And the ID is the same.

Then we open up the other file. We open the blue.html file. At that point, we see that the other connection is issued. And the ID is repeated again. And we see that the number of connections is now two. And after that, we execute the post message example from two slides ago, where we pass in the message, hello, world, into the shared worker. And so when that happens, the shared worker prints that it received a message, prints its ID again, and the message that it received. And then it dispatches those messages to the calling HTML files. And so when that happens, the event line is called, the final two event lines are printed to the screen. And those will be seen within the console for the inspector on those specific pages.

There's no sort of guarantee in this case, the order in which the right of the blue HTML logs get made. That's a bit of the fun excitement of multi threading is that there's not always a guarantee on the order in which this stuff gets executed. So, why might you use a shared worker? Well, perhaps you need to communicate across pages. You know, it's pretty useful for keeping, like, a context with variables associated with it, and particularly in cases where you want those variable scopes to outlive of the life of a page. And so perhaps some heavy, you know, single page applications might depend on this. We really want to coordinate things across different pages. So, another pattern is perhaps you want to make a singleton, you know, single, singleton, source of truth, and you want that to be accessed across pages. One thing to keep in mind is that, unfortunately, shared workers are not supported by Safari. I believe they support them at some point, but then for security considerations, they end up removing it. However, it does work in Chrome and Firefox. If you do find yourself needing a pattern to coordinate communication across different pages, you might consider using the broadcast channel as an alternative, and that is available in modern browsers as well. Now, one thing to keep in mind is that a shared worker is going to die when its last parent dies, and so if we were to open multiple pages, maybe you end up opening 10 of them, it's not until, you could then start closing these different pages and it's not until you close the final page that the shared worker would end up being killed as well.

You can also sort of manually terminate these web workers if you so choose. All right, so finally, let's take a look at service workers. What is a service worker? Well, a service worker is the most complex of the web workers. The sort of the coolest feature that they support is the ability to intercept or otherwise proxy requests that are made to a server from a web page. And so, this includes things like, oh, the fetch request, sort of AJAX requests, but also includes things like images that are loaded, assets that are loaded from CSS, the favicon file. A lot of that stuff, basically all of it ends up getting sent through the service worker.

One thing that's interesting about the service worker is that it can actually technically have zero parents, and it's sort of hand wavy, runs in the background. And so, you do need a page to run to actually end up installing the service worker. But then once that page closes, the service worker technically remains installed in the browser. Sort of the behavior on when it sort of comes and goes, when it lives and dies, that's a little bit less defined in the sense that it's not something you would necessarily want to depend on. So, you can use the service workers to share state between same origin windows as well.

All right. So, let's look at another code example. So, in this case, when we look at service workers as they're seen in the web page, again, so in this case, the interface to create the worker is a little bit different. Here we're calling navigator.service work.register. Much like with the other web workers, the first argument is a path to the file that represents the worker. There's also an additional configuration object, and the most commonly used configuration property in this is that of the scope. And so, the scope allows us to define the URL range that the worker can control. So, in this case, we're saying, you know, things that are loaded that begin with a slash end up being in control. Essentially it's saying everything on this domain is sort of under control. We also get some different state changes that we're able to hook into. In this case, we're handling the on controller change, and we're just gonna log a message to the screen. So, what that says is that, when the current page, when a service worker ends up taking control of the page, which means at that point in time that requests are intercepted, we're just gonna log a message that it is now functioning. So, the final function we have here is the make request. So, this is just for illustrative purposes, and we'll execute this in a little bit. But what this does is it just makes a fetch to a file in the current server called data.json. Deserializes the result and then logs it to the screen. Alright, so now let's check out the service workers inside the worker itself. So, this is our sw.js file. This is the first half.

So, the first thing we're doing in here is we're creating a variable called counter and we're signing it to zero. Next, we're assigning an on install method on our self object and that tells us when the service worker is being installed. So, in this case, we're just going to log a message that the install happened.

After that, we have an on activate, and so this tells this gets called when the service worker reaches the activation stage or state, as it were, these service workers act as a state machine. So, this happens, we're just going to log a message that the service worker is now active, but then we're also going to do something else that's kind of interesting. When a service worker is first activated, any pages that are open, requests that they send will not immediately get sent through this service worker. It isn't until the page is refreshed that those pages are then under control of the service worker. So, what we're doing here at the bottom, we're calling event.waitUntil, which accepts a promise, and the promise is the result of the self.clients.claim call. So, that's saying basically the pages that are currently open, the service worker will intercept the request. All right.

So, the file continues, and here's the second half. We also have this on fetch handler. This on fetch handler, this gets called every time the service worker receives a network request from one of the web pages. So, inside of this one, what we're doing is first logging the URL that was received. Next, we have an if statement, so in here, we check to see if the URL that was received ends in data.json. If it does not, then we skip to the end and we fall back essentially to a normal HTTP request. So, in here, we have this event that respond with, and that accepts a promise which resolves into a value that is given to the browser as a result of the request. And so, the value that we're giving it is then the response from fetch, which is a promise, and then the argument that we're providing to fetch is the incoming request, which is event.request. So, essentially, what that line is saying is just perform a normal request and don't really do anything with it. However, if the URL did end in data.JSON, we execute the body of that if statement. So, what we do in there is we increment that counter variable from before, and then we just call event.respondWith, you can ignore that return void, but we just call the event.respondWith, where we pass in a new response that we're creating from scratch. And so, the body of that response is a JSON object that contains our counter in the variable. And then, just for illustrative purposes, muscle setting the headers, so in this case, we're setting the content type to text.JSON. And so, if we actually execute this code, this is the logs that we'll see. So, the first thing we see is that the service worker is installed. Next, we see that the service worker has been activated. And then, finally, we see that the controller change has happened. Again, sort of the order of these messages is non-deterministic, as the browser, you know, may handle a log and buffer it in memory. Well, it will print a log from another location. So, the order of this, those first two messages, is not guaranteed.

Next, we call make request from within the webpage, and that's gonna make our fetch request to the server. So, that happens. We print that the fetch was made. It just prints the URL that was received, and then it returns the JavaScript object through the network request. And then, finally, the main.js receives that message, and then prints the result, which in this case is counter set to 1. And then, if we were to execute the make request function multiple times, each one of those requests would then result in a different counter.

And so, none of these requests actually get sent to that, to the server running at localhost port 500, they're all handled by the service worker. And so, why might you want to use a service worker? Well, it's really useful to cache network assets if an application is offline. You can use it to perform background synchronization of content that is updated, and if you update content on the server, the service worker can then sort of decide how to give that back to the client. If you want to be able to support push notifications, that's also done in the service worker. If you're like me and you like to build progressive web apps, and you like those apps to be added to the home screen, well, both Android with Chrome and iOS with Safari will make use of these service workers, and it's sort of one of the requisites before you can add your PWA to the home screen. One thing to keep in mind is that a service worker, it might die when the last parent dies, but it sort of sits around and there's not really a guarantee on how long those closures sort of remain in memory. So, if you think back to the example I had with that counter variable, that's actually a bit of an anti-pattern. You really wouldn't want to create a state in memory in a service worker where you would expect it to sort of hang around. And if you want to do things that are a bit more persistent, for example, you want to put things in caches. There's all sorts of cache APIs that are available within service workers to keep that stuff in a more persistent state. So, if you were to take a screenshot of this presentation, this is probably the one to do.

And so, here we have sort of a comparison between the different types of web workers. And so, on the far left, I have sort of the feature and then how it works for dedicated, shared, and service workers. And so, all three of these web workers, each one of them is gonna provide an additional thread which could be used for multi-threading purposes. If you have a server that's not serving content over HTTPS, but you can only use dedicated and shared workers, you are unable to use a service worker with it. If you need support Safari, you can use dedicated and service workers, but you'd have to avoid a shared worker. If you want to act as a HTTP proxy, well, then you need to use a service worker. A dedicated worker has one parent, a shared worker has at least one parent, and a service worker has at least zero parents. And then a dedicated worker dies with its parent, a shared worker dies with its last parent, and a service worker, it's a little bit trickier. All right. So that's been the presentation. This was a comparison of web workers. If you'd like to follow me, I'm on Twitter at tlhunter. This presentation is available at that bit.ly link online. And then if you're interested in finding out more information about the book, feel free to follow that last URL as well.