Mozilla, in particular, provides a Worker interface which web workers implement. While the Worker interface spawns OS-level threads, web workers use the postMessage mechanism to send messages (with serializable objects) between the two execution contexts. To ensure thread safety the worker is only given access to thread safe components to include the following:
- timers: setTimeout() and setInterval() methods
- importScripts() method
The worker script can also make use of:
- navigator and location objects
HTML5 Web Workers
As mentioned earlier, the Web worker spec defines an API for executing scripts in the background by spawning an independent execution context.
It is important to note that web workers are costly, having an impact on startup and overall memory consumption. So, they are intended to be used lightly and in conjunction with the some of the asynchronous techniques mentioned earlier. A well built client-side application would typically make use of one or two cases where tasks are expensive. Here are a few common uses cases:
- Single Page Application bootstrapping large amounts of data during initial load
- Performing long running mathematical calculations in the browser
- Processing large JSON datasets
- Text formatting, spell checking, and syntax highlighting
- Processing multimedia data (Audio/Video)
- Long polling webservices
- Filtering images in canvas
- Calculating points for a 3D image
- Reading/Writing of local storage database
Long Running Scripts
Our first web worker hack will be a long running script with heavy computation. It will execute 2 loops that output a two-dimensional array. First, we will use this computation to lock up the browser’s UI thread, and later we will move the task to a worker.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Spawning a Worker
Now let’s move our heavy computational task to a dedicated web worker, so that the user doesn’t have to wait for the script to complete execution in order to interact with user interface. First, lets spawn a new worker:
1 2 3 4 5 6
Here, we define an external file that will contain the logic of our heavy computational task. The file, highComp.js will listen for a message that will receive the serialized JSON payload, and then we will set up an additional listener to receive a message back from highComp.js.
Now, we can move this cpu-intensive task to a separate file: highComp.js
1 2 3 4 5 6 7 8 9 10 11 12 13
In highComp.js, our two dimensional array is built and set to variable a. It is then passed back to our main script via the postMessage call.
In the next hack, we will mix our use of timers with the power of a dedicated worker. As we send messages (passing serializable objects as a parameter to postMessage) back and forth to code running in the shared UI thread, our timer will periodically send and check for new messages and use their contents to modify the DOM.