by The Hungry Brain
Web workers in action: why they’re helpful, and how you should use them
In the above example, if you call average before the hello method, then your page will become unresponsive and you won’t be able to click on Hello until the execution of average gets completed.
You can see that when average is called with 10000 as input first, it took ~1.82 seconds. For that amount of time the page becomes unresponsive and you were not able to click on the hello button.
A good example of async programming is an XHR request. In this we hit an API asynchronously, and while waiting for the response, other code can be executed. But this is limited to certain use cases related to web APIs mostly.
Another way of writing async code is by using the setTimeout method. In some cases, you can achieve good results in unblocking the UI from longer-running computations by using setTimeout. For example, you can do this by batching a complex computation in separate setTimeout calls.
In this example, you can see that after you click on the Calculate Average button, you can still click on the Hello button (which in turn shows an alert message). This way of programming is surely non-blocking but takes too much time, and is not feasible in real world applications.
Here, for the same input 10000, it took ~60 seconds, which is very inefficient.
So, how do we solve these kinds of issues efficiently?
The answer is Web Workers.
What are web workers ?
Web workers are created by a constructor function Worker() which runs a named JS file.
If the specified file exists, then it will be downloaded asynchronously. If not, then the worker will fail silently, so your application will still work in case of a 404.
We will learn more about creating web workers and how they work in the next section.
A worker thread has its own context and therefore you can only access selected features inside a worker thread, like web sockets and indexed DB.
There are some restrictions with web workers:
- You can’t directly manipulate the DOM from inside a worker.
- You can not use some default methods and properties of the window object since the window object is not available inside a worker thread.
- The context inside the worker thread can be accessed via DedicatedWorkerGlobalScope or SharedWorkerGlobalScope depending upon the usage.
Features of Web Workers
There are two types of web workers:
- Dedicated web worker — A dedicated worker is only accessible by the script that called it.
- Shared web worker — A shared worker is accessible by multiple scripts — even if they are being accessed by different windows, iframes, or even workers.
Let us discuss more about those two types of web workers.
Creation of a web worker
Creation is pretty much same for both a Dedicated and Shared web worker.
Creating a new dedicated worker is simple: just call the Worker constructor and pass the path of the script you want to execute as the worker.
Creating a new shared worker is pretty much the same as that of a dedicated worker, but with a different constructor name:
Communication between main and worker thread
Communication between the main thread and worker thread happens via the postMessage method and onmessage event handler.
In the case of a dedicated web worker, the communication system is simple. You just need to use the postMessage method whenever you want to send a message to the worker.
And inside a web worker you can respond when the message is received by writing an event handler block like this:
The onmessage handler allows you to run some code whenever a message is received.
Here we are calculating the average of numbers and then using postMessage() again to post the result back to the main thread. As you can see on line 6 in main.js we have used the onmessage event on the worker instance. So whenever the worker thread uses postMessage, onmessage in the main thread gets triggered.
In the case of a shared web worker, the communication system is a little different. As one worker is shared between multiple scripts, we need to communicate via the port object of the worker instance. This is done implicitly in case of dedicated workers. You need to use the postMessage method whenever you want to send a message to the worker.
Inside a web worker (main-shared-worker.js) it is a little complex. First, we use an onconnect handler to fire code when a connection to the port happens (line 2). We use the ports attribute of this event object to grab the port and store it in a variable (line 4). Next, we add a message handler on the port to do the calculation and return the result to the main thread (line 7 and line 25) like this:
Termination of a web worker
If you need to immediately terminate a running worker from the main thread, you can do so by calling the worker’s terminate method:
The worker thread is killed immediately without an opportunity to complete its operations.
Spawning of web worker
Workers may spawn more workers if they wish. But they must be hosted within the same origin as the parent page.
Worker threads have access to a global function, importScripts(), which lets them import scripts.
We have discussed some of the approaches above to achieve async programming so that our UI doesn’t get blocked due to any heavy computational task. But there are some limitations to those approaches. So we can use web workers to solve these kind of problems efficiently.
Click here to run this live demo.
Here, you will see 3 sections:
- Blocking Code: When you click on calculate average, the loader does not display and after some time you see the final result and time taken. This is because as soon as the average method gets called, I have triggered the showLoader method also. But since JS is single threaded, it won’t execute showLoader until the execution of average gets completed. So, you won’t be able to see the loader in this case ever.
- Async Code: In this I tried to achieve the same functionality by using the setTimeout method and putting every function execution into an event loop. You will see the loader in this case, but the response takes time as compared to the method defined above.
- Web worker: This is an example of using a web worker. In this you will see the loader as soon as you click on calculate average and you will get a response in the same time as of method 1, for the same number.
You can access the source code for the same here.
There are some advanced concepts related to web workers. We won’t be discussing them in detail, but its good to know about them.
- Content Security Policy — Web workers have their own execution context independent of the document that created them. Because of this, they are not governed by the Content Security Policy of the parent thread/worker. The exception to this is if the worker script’s origin is a globally unique identifier (for example, if its URL has a scheme of data or blob). In this case, the worker inherits the content security policy of the document or worker that created it.
- Transferring data to and from workers — Data passed between the main and worker thread is copied and not shared. Objects are serialized as they’re handed to the worker, and subsequently, de-serialized on the other end. The page and worker do not share the same instance, so the end result is that a duplicate is created on each end. Browsers implemented the Structured Cloning algorithm to achieve this.
- Embedded workers — You can also embed the code of worker inside a web page (html). For this you need to add a script tag without a src attribute and assign a non-executable MIME type to it, like this:
There are a lot of use cases to use web workers in our application. I have just discussed a small scenario. Hope this helps you understand the concept of web workers.
Thank you for reading.
Happy Learning :)
Originally published at www.thehungrybrain.com.