Javascript Worker Threads – the Unsung Hero of Modern Browsers

The release of Firefox 3.5 and Safari 4 a few weeks before it heralded the implementation of a feature that I believe will push web application development into the next age. The feature, called Javascript web workers, will allow web apps to have far more advanced features without the slowdown experienced even with today’s Javascript-heavy websites.

So what is a web worker? Broadly speaking, it is a way to implement threading in Javascript. If you aren’t familiar with threading, it is essentially the ability to split your application into multiple sections, called threads, that can run in parallel. This means big things for Javascript driven web sites – imaging having your main Javascript handling the user interaction side of things, while a separate thread is running in the background polling your server for new information, which can then be passed back to the main thread to display to the user. Instead of having to throw together setIntervals and the like, it can all be happening in the background with no disruption to the user.

A good example of this in practice is Google Reader. It could benefit from implementing web workers in two places: the infinite scrolling feature, which loads more items as you are scrolling past the current list of items, and the polling it does to update unread counts on the left pane. I notice the slowdown whenever either of these events happens, and both could easily be shifted into separate threads.

Firefox 3.5 and Safari 4 now implement web workers as described in the WHATWG’s draft specification (give or take). Browsers that support Google Gears, including Google Chrome, also support web workers through a separate implementation, described in Google’s WorkerPool API documentation. While spawning a thread takes different calls, inter-thread communication is handling the same way, and a library called jsworker is already available to wrap the two implementations.

Mozilla’s example of setting up a web worker thread shows just how easy it is to throw some code in a JS file and spawn it as a thread, and I’d encourage anyone interested to give it a read.

Comments

  • engetlyJedync
    This look interesting,so far.
    If there's anyone else here, let me know.
    Oh, and yes I'm a real person LOL.

    Bye,
  • Yes, the Safari 4 and Firefox 3.5 implementations of worker threads use OS level threading, which means it makes use of multiple cores and multiple threads per core.

    I don't agree that it's a replacement for event driven development. I think they go hand in hand very well, it just brings more desktop-type development techniques to the web.

    Think ... Read Moreof an email client on the desktop - it has background threads to perform fetching of mail, and events to control when people interact with the already delivered mail, then more threads to send info back to the server (especially in the case of an IMAP account). This kind of thing will open up a lot of opportunities on the web.
  • you know... I gave it some more thought.. and you examples would work better in threads if the threads can run over multiple CPUs... have you got any deets on that?
  • there is not really much difference, just that a lot of front end developers don't understand how to write good event driven code. Threads always have and will be the lazy way to get concurrency for people who can't think in terms of events :P

    That being said, hopefully this will enable developers to create sites that run better and smoother because it gives them concurrency in a paradigm they understand (linear code execution)
blog comments powered by Disqus