CHAPTER 10 USING THE WEB WORKERS API
Browser Support for Web Workers
The majority of the modern web browsers support Web Workers. Check the web site http://caniuse.com (search for Web Workers) for the most up-to-date support matrix. While there are polyfill (emulation) libraries available for most other APIs—for example, for HTML5 Canvas there are libraries such as excanvas.js and flashcanvas.js that provide an emulation of the Canvas APIs (using Flash under the covers)—an emulation for Web Workers does not make a lot of sense, however. You can either call your worker code as a worker, or run the same code inline in your page, blocking the UI thread. The improved responsiveness of the worker-based page may just be enough to have people upgrade to a more modern browser (at least we hope it will).
Using the Web Workers API
In this section, we’ll explore the use of the Web Workers API in more detail. For the sake of illustration, we’ve created a simple browser page: echo.html. Using Web Workers is fairly straightforward—you create a Web Worker object and pass in a JavaScript file to be executed. Inside the page you set up an event listener to listen to incoming messages and errors that are posted by the Web Worker and if you want to communicate from the page to the Web Worker, you call postMessage to pass in the required data. The same is true for the code in the Web Worker JavaScript file—event handlers must be set up to process incoming messages and errors, and communication with the page is handled with a call to postMessage.
Checking for Browser Support
Before you call the Web Workers API functions, you will want to make sure there is support in the browser for what you’re about to do. This way, you can provide some alternate text, prompting the users of your application to use a more up-to-date browser. Listing 10-1 shows the code you can use to test for browser support.
Listing 10-1. Checking for Browser Support
function loadDemo() {
if (typeof(Worker) !== "undefined") { document.getElementById("support").innerHTML =
"Excellent! Your browser supports Web Workers";
}
}
In this example, you test for browser support in the loadDemo function, which might be called when the page is loaded. A call to typeof(Worker) will return the window’s global Worker property, which will be undefined if the browser doesn’t support the Web Workers API. In this example, the page is updated to reflect whether there is browser support by updating a previously defined support element on the page with a suitable message, as shown at the top of Figure 10-2.
242
CHAPTER 10 USING THE WEB WORKERS API
Figure 10-2. Example of showing whether Web Workers is supported
Creating Web Workers
Web Workers are initialized with the URL of a JavaScript file, which contains the code the worker will execute. This code sets event listeners and communicates with the script that spawned it. The URL for the JavaScript file can be a relative or absolute URL with the same origin (the same scheme, host, and port) as the main page:
worker = new Worker("echoWorker.js");
Inline Workers
To start a worker you need to point to a file. You may have seen some examples of script elements that have the type javascript/worker, as shown in the following example:
<script id="myWorker" type="javascript/worker">
Don’t let this fool you into thinking that you can simply set the type of a script element to run the JavaScript code as a Web Worker. In this case, the type information is used to signal the browser and its JavaScript engine not to parse and run the script. In fact, the type may as well have been anything other than text/javascript. The script example shown is a building block for inline Web Workers—a feature that can be used only if your browser also supports the File System API (Blob Builder or File Writer). In that case you can programmatically find the script block (in the previous case, the element with the myWorker id) and write the Web Worker JavaScript file to disk. After that, you can call the inline Web Worker in your code.
Shared Workers
There is yet another type of worker, which is not widely supported at the time of this writing: the shared Web Worker. A shared Web Worker is like a normal Web Worker, but it can be shared across multiple pages on the same origin. Shared Web Workers introduce the notion of ports that are used for PostMessage communication. Shared Web Workers can be useful for data synchronization among multiple pages (or tabs) on the same origin or to share a long-lived resource (like a WebSocket) among several tabs.
The syntax for starting a shared Web Worker is as follows:
sharedWorker = new SharedWorker(sharedEchoWorker.js');
243
CHAPTER 10 USING THE WEB WORKERS API
Loading and Executing Additional JavaScript
An application composed of several JavaScript files can contain <script> elements that synchronously load JavaScript files as the page loads. However, because Web Workers do not have access to the document object, there is an alternative mechanism for synchronously importing additional JavaScript files from within workers—importScripts:
importScripts("helper.js");
Importing a JavaScript file simply loads and executes JavaScript into an existing worker. Multiple scripts can be imported by the same call to importScripts. They are executed in the order specified:
importScripts("helper.js", "anotherHelper.js");
Communicating with Web Workers
Once the Web Worker is spawned, you can use the postMessage API to send data to and from Web Workers. This is the same postMessage API that is used for cross-frame and cross-window communication. postMessage can be used to send most JavaScript objects, but not functions or objects with cyclic references.
Let’s say that you want to build a simple Web Worker example that allows users to send a message to a worker, which in turn echoes back the message. This example may not be very useful in real life, but it’s useful enough to explain the concepts you need to build more complex examples. Figure 10-3 shows this example web page and its Web Worker in action. The code for this simple page is listed at the end of this section.
244