HTML5 LogoImplementing an HTML5 Web Worker is all about instantiating the Worker() constructor, creating event listeners, and posting messages between the Worker and the script that started it.

In Part I of this article, we made the case for Web Workers. We discussed the oh-so nasty concept of locking up the browser and how the single-threaded nature of JavaScript ensures that long-running scripts will send visitors away none-to-pleased. In this second part, we will use a Web Worker to pass off our “crunch” function to a separate thread, keeping the browser responsive and completely available to the user.

Part II : A Simple Web Worker

Example # 1

In Example # 1, we instantiate the Worker() constructor, passing it the name of a JavaScrpt file that has already been created and which contains the web-worker code. This file must be on the same domain as the page that calls it. In our case, it is in the exact same folder as the web page, so the path to the file is simply the name of the file: “worker.js”.

After instantiating the Worker() constructor, we add an event listener. This allows the worker file that we specified (i.e. worker.js) to send a message to the script that started the worker. The anonymous function that is the second argument of the addEventListener() method takes an event object as an argument (in this example, we call it “e;” you can name it anything you like). In this anonymous function, we remove a CSS class from the target DOM element, and then fill that element with whatever message the worker sent us. That message is contained in the “data” property of the event object (i.e. “”).

Application Web Root
The Web Root – Web Page and Separate WebWorker File

Example # 2

In Example # 2, we have an abbreviated version of the click event handler for the “Crunch some numbers” button. What I wanted to illustrate is that we “start” the worker by sending it a message.

Example # 3

In Example # 3, we have the code for our Web Worker (i.e. the file worker.js). While all of the code in the script is evaluated and executed when we instantiate the Worker() constructor (just like any JavaScript file), the code inside of the self.addEventListener() call only executes when the worker receives a message. In this example, we set the variable “msg” equal to the “crunch()” function. Our crunch() function takes anywhere between one and ten seconds to return, simulating that nasty number-crunching behavior we have been talking about.

When crunch() does finally return, we post a message back to the script that started the worker. In this case, the message is the return value of crunch(): a string of markup that says “I’m done…” and tells us how long it took.

Click here for the full working demo of Example # 2:

When you clicked the “Crunch some numbers” button, you were still able to resize the box, or do anything else you wished. The number crunching work was passed off to our Web Worker, which ran in a separate thread, which left the browser completely responsive and available to you.

This is a major improvement over the example in Part I of this article! In Part III, we will expand this demo to include a second number-crunching task, illustrating how we can spawn not only one, but multiple tasks to other threads using Web Workers.


In this article, we were introduced to the workings of Web Workers. We learned how to instantiate a Web Worker, start the Worker, post a message to it, and create an event listener so that we can respond when the Web Worker sends us a message, and access that message. We also learned how to setup an event listener in the Worker file, and post messages back to the script that started the worker.

Helpful Links for Implementing HTML5 Web Workers