Mozilla

using web workers: working smarter, not harder

This article is written by Malte Ubl, who has done a lot of great work with using Web Workers as part of the bespin project.

In recent years, the user experience of web applications has grown richer and richer. In-browser applications like GMail, Meebo and Bespin give us an impression of how the web will look and feel in the future. One of the key aspects of creating a great user experience is to build applications that are highly responsive. Users hate to wait and they hate those moments where an application seems to work for a while, then stops responding to their input.

At the core of modern client-side web applications lies the JavaScript programming language. JavaScript and the DOM that it talks to is inherently single-threaded. This means that in JavaScript only one thing can happen at any given time. Even if your computer has 32 cores it will keep only one of those cores busy when it’s doing a long computation.  For example if you calculate the perfect trajectory to get to the moon it won’t be able to render an animation that shows the trajectory at the same time and it won’t be able to react to any user events like clicks or typing on the keyboard while it’s doing that calculation.

Concurrency

To maintain responsiveness while performing intense computations concurrency is a part of most modern programming languages. In the past concurrency was often achieved by the use of threads. Threads, however, make it increasingly hard for the programmer to understand the program flow which often leads to very hard to understand bugs and chaotic behavior when different threads manipulate the same data simultaneously.

Web Workers, which were recommended by the WHATWG, were introduced in Firefox 3.5 to add concurrency to JavaScript applications without also introducing the problems associated with multithreaded programs. Starting a worker is easy – just use the new Worker interface.

In this example the worker.js file will be loaded and the a new thread will be created to execute that code.

// Start worker from file "worker.js"
var worker = new Worker("worker.js");

Communication between the main UI thread and workers is done by passing messages using the postMessage method. postMessage was added for cross-window communication in Firefox 3. To send a message from the worker back to the page, you just post a message:

// Send a message back to the main UI thread
postMessage("Hello Page!");

To catch the message from the worker, you define an “onmessage” callback on the worker object. Here we just alert the event data that is passed to the callback function. In this case, “event.data” contains the “Hello Page!” string that was sent above.

worker.onmessage = function (event) {
  alert(event.data);
  // Send a message to the worker
  worker.postMessage("Hello Worker");
}

To send a message to the worker we call the postMessage method on the worker object. To receive these messages inside the worker, simply define an onmessage function that will be called every time a message is posted to the worker.

Error Handling

There are two levels at which you can recover from runtime errors that occur in a worker. First, you can define an onerror function within the worker. Second, you can handle errors from the outside the worker by attaching an onerror handler on to the worker object:

worker.onerror = function (event) {
  alert(event.message);
  event.preventDefault();
}

The event.preventDefault() method prevents the default action, which would be to display the error to the user or at least show it in the error console. Here we alert the error message instead.

Shared Nothing

Workers share absolutely no state with the page they are associated with or with any other workers; the only way they can interact at all is through postMessage. Workers also have no access to the DOM, so they can not directly manipulate the web page. There is thus no risk of problems with data integrity when multiple workers want to manipulate the same data at once.

A standard setup that is using workers would consist of a page JavaScript component that is listening for user events. When an event occurs that triggers an intensive calculation a message is sent to the worker which then starts the computation. The script on the page, however, can terminate immediately and listen for more user events. As soon as the worker is done, it sends a return message to the page which can then, for example, display the result.


The unresponsive script warning that is being displayed by browsers when a script is taking a long time to execute is a thing of the past when using web workers.

The Fibonacci Example

Next is an example of a worker that calculates the Fibonacci numbers from 0 to 99 in the background. Actually, because calculating Fibonacci numbers using this very inefficient method can take a lot of time for larger numbers (as in greater than something like 30) the script might never finish on your computer (or crash because it blows out the stack), but when doing it in a worker this has no effect on the responsiveness of the main web page. So you can still draw a complex animation to make the waiting time for the next number a little more fun.

This HTML page contains a script that starts a worker from the file “fib-worker.js”. Messages from the worker are displayed on the browser’s console using console.log.



    
      
      
    
    
    

The JavaScript file that implements the worker contains a loop that calculates Fibonacci numbers and sends the result to the page.

// File fib-worker.js
function fib(n) {
   return n < 2 ? n : fib(n-1) + fib(n-2);
}

for(var i = 0; i < 100; ++i) {
   postMessage({
      index: i,
      value: fib(i)
   })
}

In the example above we see that we can also pass complex objects to the postMessage. These objects can contain everything that can be transmitted via JSON. This means that functions cannot be passed across worker boundaries and that the objects are passed by value rather than by reference.

Worker APIs

Workers support a function called importScripts. You can use this to load more source files into the worker.

importScripts("file.js");
importScripts("foo.js", "bar.js");

When you pass multiple parameters to the function the scripts will be downloaded in parallel but executed in the order of definition. The function does not return until all scripts have been downloaded and executed.

Here we load an external JavaScript file that calculates SHA-1 hash sums from strings and then we use it to hash responses from AJAX requests. We also use the standard XMLHttpRequest object to retrieve the content of the URL which is passed in via the onmessage event. The interesting part is that we don't have to worry about making the AJAX request asynchronous because the worker itself is asynchronous with respect to page rendering, so a little waiting for the HTTP request does not hurt as much.

importScripts("sha1.js")

function onmessage(event) {
    var xhr = new XMLHttpRequest();
    xhr.open('GET', event.data, false);
    xhr.send();
    postMessage(sha1(xhr.responseText));
}

Other APIs Available to Workers

Workers may use XMLHttpRequest for AJAX requests as seen above and access the client sided database using web storage API. Here the APIs are identical to their usage in regular JavaScript.

The setTimeout and setInterval (and the clearTimeout and clearInterval friends) functions, which enable executing code after a given period of time or at certain intervals, are also available within the worker as is the well known navigator object, which can be inspected to get information about the current browser.

More APIs may be added in the future.

Browser Compatibility

As of this writing (and to the knowledge of the author), Firefox 3.5 is the only browser that supports the ability to pass complex objects via postMessage and that implements the extended APIs defined above. Safari 4 implements a very basic version of the Worker API. For other browsers it is possible to use Workers via Google Gears, which originally introduced the concept to browsers.

Real World Usage

In the Bespin project, which is a browser based source code editor, we successfully used workers to implement CPU intensive features like real-time source code error checking and code completion. We also created a shim that implements the Worker API in terms of Google Gears and which adds the missing features to the worker implementation of Safari 4 and also moved to using transparent custom events on top of the postMessage interface. These components will be released as a stand-alone library to be usable in other projects in the future.

Web Workers will play an important role in making the Open Web an even more powerful platform for sophisticated applications. Because in the end all they do is execute JavaScript, it's easy to make scripts work on clients which do yet have the luxury of web workers. So go ahead and add them to your applications today to make them feel just a little more responsive and more pleasant to use.

Posted by on at

17 comments

Comments are now closed.

  1. Theodora Vorbix wrote on July 8th, 2009 at 6:43 pm:

    Can we pass a function to a worker instead of a script?

    like:

    var worker = new Worker(fibonacci(data),oncallback);

  2. Malte wrote on July 8th, 2009 at 11:06 pm:

    @Theodora: No that is not possible, because the function might be a closure which holds on to DOM or other objects which would violate the security as well as the isolation guarantees.
    The projects http://www.nonblocking.io/2009/03/offloading-arbitrary-js-objects-to.html tries do to something similar with JS objects, though (using source serialization).

  3. Funtomas wrote on July 9th, 2009 at 3:42 am:

    Can I pass a JSON object in the message, like “build up a graph of those”?

  4. dataStorm wrote on July 9th, 2009 at 8:25 am:

    Thanks for the article!
    Is there a way(maybe someone has a link?) to load the scripts with web workers and if those are not supported then just load it the old way? (without repeating the scripts). I would like to start implementing this new technology but it has to degrade nicely.

  5. Malte wrote on July 9th, 2009 at 2:12 pm:

    If you like to put on your diving suit and dive into dangerous waters you might want to try to integrate the piece of software we use in bespin which will eventually be its own project: http://www.nonblocking.io/2009/03/offloading-arbitrary-js-objects-to.html

  6. datastorm wrote on July 9th, 2009 at 4:07 pm:

    Were you talking to me?

  7. Jesse Ruderman wrote on July 10th, 2009 at 1:32 pm:

    You can’t pass functions to workers because they “might” be closures? Why not just disallow instantiating workers with functions that *do* lexically refer to an outer scope, and allow the rest? Spidermonkey already keeps track of this to perform various optimizations; the so-called “null closure” optimization was first added in bug 452498.

    Passing a function to a worker seems more natural to me than passing a file.

  8. Pingback from Mozilla Hacks: Korzystanie z Web Workers « marcoos.techblog on July 19th, 2009 at 8:29 am:

    [...] Comment! W ramach serii tłumaczeń artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie artykułu Using Web Workers – Working Smarter, Not Harder. [...]

  9. marcoos wrote on July 19th, 2009 at 8:34 am:

    I’ve posted a Polish translation of this article here: http://blog.marcoos.com/2009/07/19/mozilla-hacks-korzystanie-z-web-workers/ :)

  10. Pingback from Web Workers - Threads em Javascript - Klaus Paiva on July 22nd, 2009 at 3:16 pm:

    [...] hacks.mozilla.org: using web workers: working smarter, not harder [...]

  11. Pingback from Mozilla Hacks: Nieprzezroczystość w Firefoksie 3.5 « marcoos.techblog on July 23rd, 2009 at 12:11 pm:

    [...] artykułów z bloga Mozilla Hacks, przedstawiam dzisiaj tłumaczenie (króciutkiego) artykułu Opacity in Firefox 3.5, autorstwa Chrisa [...]

  12. Pingback from Experimenting with web workers | NCZOnline on August 18th, 2009 at 6:01 am:

    [...] the past couple of months, there’s been some good information floating around about web workers. I have no desire to add yet another introduction to the topic into the blogosphere, [...]

  13. Pingback from 5 years of Firefox at hacks.mozilla.org on November 8th, 2009 at 4:46 pm:

    [...] the future of web applications – super fast JavaScript, modern CSS, HTML5, support for the various web-apps standards, downloadable font support, offline application support, raw graphics through canvas and WebGL, [...]

  14. Pingback from 火狐五周岁──记录互联网变化的五年 < MJiA on November 9th, 2009 at 12:15 am:

    [...] 在过去五年中很明显改变的一件事情是在众多现代浏览器──Firefox、Safari、Opera和Chrome──同世界最流行浏览器──IE之间各个方面产生的巨大差异。现代浏览器是为了未来那些互联网应用构建──超级快速的JavaScript,现代CSS,HTML5,支持多样的互联网应用标准,支持可下载字体,支持离线应用,通过canvas 和 WebGL支持原生图像处理,原生视频支持,高级XHR支持兼具高级安全工具和网络能力。 [...]

  15. Pingback from 谋智社区 » Blog Archives » 火狐五周岁──记录互联网变化的五年 on November 9th, 2009 at 5:02 am:

    [...] 在过去五年中很明显改变的一件事情是在众多现代浏览器──Firefox、Safari、Opera和Chrome──同世界最流行浏览器──IE之间各个方面产生的巨大差异。现代浏览器是为了未来那些互联网应用构建──超级快速的JavaScript,现代CSS,HTML5,支持多样的互联网应用标准,支持可下载字体,支持离线应用,通过canvas 和 WebGL支持原生图像处理,原生视频支持,高级XHR支持兼具高级安全工具和网络能力。 [...]

  16. Pingback from web workers를 사용하여 더 스마트하면서 힘들지 않게 동작시키기 ✩ Mozilla 웹 기술 블로그 on June 18th, 2010 at 1:10 am:

    [...] 원저자: Eric Shepherd – 원문으로 가기 [...]

  17. Jason wrote on July 9th, 2010 at 5:55 pm:

    Unfortunately, because they don’t have access to the DOM, they’re practically worthless for real-world applications unless you have some crazy requirements (like recursively calculating the Fibonacci sequence). If I could use them to render graphs and pass them back, now that would be something. The fact that they’re limited to passing back strings only SEVERELY limits their usefulness.

Comments are closed for this article.