The HTML5 Family: Web Workers
Tweet
Web Workers are brand new in the HTML5 Family and provide a new way of performing processor-intensive tasks. Heavy computing has historically been difficult to achieve using JavaScript on the browser. This was due to two things — JavaScript's poor performance and its single threaded nature. The first of these issues has been given a lot of attention in recent years, with browsers competing intensely on JavaScript speed. In the last two years, engines like Chrome's V8 and Safari's Nitro, have made single-threaded performance pretty good.
setTimeout to circumvent this restriction.
While that worked, we now have a better solution in the form of Web Workers. Workers are typically simple scripts that run in a separate thread. One great benefit of this is that their execution does not block the UI. No matter how much number crunching a worker is doing, the UI remains responsive.
How Web Workers Work
Web Workers exist almost independently of the page that spawned them. The worker has no access to the spawning page's DOM, and cannot communicate with it directly. All communication between the page and the worker is performed asynchronously via callback functions that accept message strings. Let's construct a simple Worker to see how it works:
//code in the spawning page
var worker = new Worker('worker.js');
worker.onmessage = function(event) {
alert("Worker says: " + event.data);
};
worker.postMessage('Dave');
Above we've created a new Worker by simply calling its constructor with the name of a JavaScript file to load. This is an important and initially surprising part of the design of Workers. However, if a Worker could instead be constructed by passing in a function to execute, it would be trivial to pass in a closure with a reference to the DOM or other page elements, allowing the Worker free access to the spawning page. This threat is greatly diminished, by separating the file and only allowing communication via string messages.
After constructing the Worker, we set up a callback function that accepts an event object. This is the means by which the Worker can communicate with the spawning page. Finally, we post a message to the worker to kick the process off. Let's see what our worker.js looks like:
//worker.js
onmessage = function(event) {
var message = "Your name is " + event.data;
postMessage(message);
};
Our worker is extremely simple and just joins two strings together. We listen for the message that we passed in with the spawning page's call to postMessage by defining the worker's onmessage function. After the trivial processing we perform, the worker calls its own postMessage function, which is picked up by the spawning page in the function that we set on worker.onmessage. The outcome of running this code is that the string, "Worker says: Your name is Dave", is alerted.
Using a Worker for such a simple operation is clearly a case of over-engineering, but the simple processing we performed above can be replaced by almost anything. We could pass worker.js a dataset to transform, an image to analyse or any other intensive computing task.
Workers Everywhere
Of course, we are not limited to spawning a single worker. Large tasks can often be split into smaller subsets in a divide and conquer strategy. This rewards of this approach largely depend on how parallel your processing is — if you have 100,000 records to process in some way and the processing of each record does not depend on the other, you can spawn a large number of Workers. With the trend towards many-core CPUs set to continue for the foreseeable future, this is clearly a scaleable approach. A few more interesting facts about Workers: they can spawn each other, talk to each other and even be shared between pages. Recursive algorithms get a boost from this, especially those recursing over tree structures. Each node can be processed by a different worker which reports back to the master worker, which in turn reports back to the spawning page. This is useful as it allows us to move all the multiple-Worker spawning logic into a worker script and keep the page logic simple. Web Workers are available in Firefox 3.5+, Chrome 4+ and Safari 4+. Web Workers are not supported in any version of Internet Explorer, and at the time of writing it seems they will not be present in IE9 either. Web Workers will be great for speeding up computation on compatible browsers, but a fallback mechanism will be required for the foreseeable future.
Web Workers are available in Firefox 3.5+, Chrome 4+ and Safari 4+. Web Workers are not supported in any version of Internet Explorer, and at the time of writing it seems they will not be present in IE9 either. Web Workers will be great for speeding up computation on compatible browsers, but a fallback mechanism will be required for the foreseeable future.
The HTML5 Family
Our continuing coverage of the many technologies which make up what people refer to as “HTML5”, we call The HTML5 Family. See all our published posts here:
- A HTML5 Primer for the Overwhelmed
- Web Storage
- CSS3
- Web Workers « Currently reading
There are 24 responses. Add yours.
Wayne
2 years agoExcellent article, enjoying the entire series so far. Thank You.
Rick Waldron
2 years agoIf you’re interested, I’ve published a lot of research and development as well as browser progress regarding Web Workers at http://weblog.bocoup.com
Jay Robinson
2 years agoExcellent stuff, Rick. Thanks a lot!
tumblr
2 years agoExcellent post, Thanks a lot! And great demo. I like it.
Shyru
2 years agoGreat article, however I miss the link to ExtJS. What type of performance improvements could be achieved when using WebWorkers in ExtJS in the future? Do you see any slow tasks that could be performed in the background? Or what long running tasks could be breaked out to WebWorkers for application developers using ExtJS?
In my experience (now that javascript-performance is pretty good) the number one performance problem in RIAs is DOM-manipulation and rendering/drawing. For example, when our app loads a very complicated and big grid with 500 rows of data, the loading takes 1-2 seconds, but the rendering takes almost 20 seconds! (In Firefox that is) - Even worse in IE. I see no way of speeding things like this up with WebWorkers, especially as the browser with the poorest javascript performance (IE) does not support WebWorkers at all…
So what is the link to ExtJS and applications developed with ExtJS? How could they practically use the potential of WebWorkers to speed things up?
Ed Spencer
2 years ago@Shyru the upcoming PivotGrid component is a great candidate for the use of Web Workers. That component often needs to transform large numbers of records, which could be done with background processing if workers are available.
I agree it’s ironic that the worst performing browsers have the worst support for workers - such is often the case sadly.
mdmadph
2 years agoIf Web Workers were supported in IE, I’d be building them into my dev right now. As is, I can’t. :(
camelCase
2 years agoI think this HTML5 series is good for the image of ExtJS Inc but the material to date feels incomplete without reference to what this means for ExtJS. Maybe the subject for a final wrap-up article?
e.g. How would I serialise an Ext DataStore to local client storage and then rehydrate it? Or how could I poll a remote website from a worker, parse the result in the worker thread and then poke selective data updates into the store of an existing rendered ExtJS grid?
Jay Robinson
2 years ago@camelCase, Stay tuned!
Leonard
2 years ago@Ed Spencer
The most exiting thing on this page I’ve seen is the hint about an upcoming PivotGrid component. Is this going to be an official component? Is there anywhere we can find more info on the component?
Is this going to work purely with local store data, or will we be able to link to server using Direct or REST, or maybe even a new MDX extension thereby supporting drillthrough? So many questions….
Thanks,
Leonard
Ed Spencer
2 years ago@Leonard I’ll direct you to our Roadmap page, which has some information on upcoming components. It will work with any type of store, though it might not support Web Workers as of the 3.3 release.
Ivan Zuzak
2 years agoCool overview of workers!
Several WebWorker-related projects worth checking out:
1) Metaworker – mapreduce with workers – http://bit.ly/7oTuS5
2) Pmrpc – RPC/pubsub communication with workers and windows/iframes – http://bit.ly/JMtkm (I’m one of the developers)
3) jQuery Hive – creating and managing web workers across implementations – http://bit.ly/c5ihqm
4) Javascript Enumerable.Map() with WebWorkers – http://bit.ly/cY8M9P
p6ril
2 years agoExcellent serie of articles which gives a great overview of all the new upcoming web technologies. First time I read about web workers. Thanks for sharing all these information and keep doing so
Moses Ting
2 years agoAgreed, excellent series of articles regarding the new additions to HTML5. Thanks for taking the time to craft these informative articles.
Werbeagentur Lübeck
2 years agoI think this HTML5 series is good for the image of ExtJS Inc but the material to date feels incomplete without reference to what this means for ExtJS. Maybe the subject for a final wrap-up article?
Rick
2 years ago@Ivan Zuzak - thanks for the plug!
Now that Safari 5 and Chrome 5 are fully supporting complex message in postMessage(), I’m getting more and more excited to see how IE9 implements.
Michael Mullany
2 years agoHi Werb. Yes we definitely have a wrap up article coming soon. Just wanted to lay out all the HTML5 goodies first.
Jeremy
2 years agoGreat post. Some thing that I don’t understand…
Shouldn’t it be
//worker.js
postmessage = function(event) {
...
onMessage(message);
}
instead of
//worker.js
onmessage = function(event) {
...
postMessage(message);
};
or are these predefined functions
Neil McLachlan
2 years agoWith regard to how these new HTML 5 features fit into the world of ExtJS, my assumption the whole time is that where-ever possible, ExtJS will be leveraging this stuff for us, in the background, and simply exposing the benefits through the regular ExtJS API.
Part of ExtJS’s appeal is the abstraction of differences between browsers and versions of HTML and Javascript, so if I’m writing an app using ExtJS I would expect (for example) that it will decide if web workers are available and there is a benefit to using them, on a client-by-client basis, so that I don’t have to worry about it. I will just keep instantiating ExtJS objects as always and benefits will magically materialise if available.
Similarly, the datastore objects in ExtJS will simply be expanded to include options for the new web storage facilities.
Of course, I still want to *know* about the new features and understand when and how they should or could be used. Which is why I’m reading all these articles.
Ed Spencer
2 years ago@Jeremy they are predefined functions
@Neil we absolutely agree, and will continue to take this approach
Ramkho
1 year agoGood work man. i ‘ve tested webworker feature in opera, chrome and firefox. Opera is working good. But in chrome its not and in mozilla the video which runs in my foreground strucks when external js is rendering.
Can anyone pl say wat xactly is the pb with those browsers ??
Gabriel
1 year agoExcellent article, enjoying the entire serie so far, where I can find more documentation and tutorials about sencha touch?
wiersze
1 year agoInteresting article, I invite others to read
refrigerator repair
8 months agosito web Sweet, non mi ero imbattuto in un blog nelle mie ricerche! proseguire il lavoro fantastico!
Comments are Gravatar enabled. Your email address will not be shown.
Commenting is not available in this channel entry.