At the Forge - Communication in HTML5

Finally, another intriguing addition to HTML5 is the notion of Web workers, which you can think of as the browser equivalent of threads. Perhaps you have a complex task that needs to be handled in parallel with rendering of a page or of downloading information from the Internet. By splitting the work across two Web workers, you can take advantage of today's modern, multiprocessor computers to get a faster result. Because Web workers operate in the background, rather than on the thread that handles displaying the page, the page should be more responsive than if everything were in one thread.

Now, I must admit I generally have tried to avoid programming with threads, because of the many problems that can crop up whenever you have shared resources. Given that JavaScript was never designed to work with threads, my first thought when I heard about Web workers was how this possibly could work while keeping data safe and the browser stable. The solution appears to be sound, although it's still too early for me (and many others) to know for sure.

The idea is this. You launch a Web worker by creating a new Worker object:

var worker = new Worker("code.js");

Notice that you hand the name of a file to a Web worker. You cannot hand it a piece of code, either directly or by passing it a function reference. Perhaps it eventually will be possible for a browser-based application to create dynamically, and then store (using WebSockets?) a file on the server, but the main purpose of this restriction is to ensure that there is no chance for shared data among the various Web workers, thus avoiding the chance for issues traditionally associated with threads.

Indeed, Web workers operate almost as if they existed on different computers, with no direct connections between them. Workers cannot access the DOM, which means any elements on the page. Functions and data in the main thread are not available to the Web workers, and vice versa.

This raises the question of how the main thread and Web workers can communicate. The answer probably won't surprise you. They use postMessage(), the same mechanism for message passing that can be used to send information from one window or tab to another, regardless of origin.

I can foresee a number of uses for Web workers. First, they will allow browser-based applications to handle more than one thing at a time, ensuring that the main thread is used for rendering the UI and interacting with the user. Second, it means you can start to break problems apart, taking advantage of modern computer hardware that can put different threads on different processors intelligently. Finally, it means JavaScript now has the beginnings of a built-in message-passing mechanism. And, although programs still must remain inside a single browser, I have to assume at some point, it'll be possible to open a Web worker not just on your local machine, but on a remote one, as well.

Marc Andreessen, who wrote the original Mosaic browser and helped to popularize the Web as a founder of Netscape, claimed years ago that the browser is the new operating system. Even as Ajax and other advanced Web technologies have advanced during the past few years, and such amazing browser-based applications as Google Docs have emerged, I still have been skeptical of whether Web-based applications ever will truly rival their desktop counterparts. The addition of cross-window communication, WebSockets and Web workers go a long way toward convincing me that Andreessen's prediction has nearly come true.

HTML5 and its associated technologies include a wealth of new options for developers. It will take some time to figure out how well these work, how to get around the fact that not all browsers support them and just how useful (or not) various features might be. If you are a Web developer, I encourage you to study and work with these technologies as soon as possible. I already have changed the architecture of some of my applications as a result, and I wouldn't be surprised if that happens to you too.