Web Workers - parallel javascript tasks for the masses

download Web Workers - parallel javascript tasks for the masses

of 1

Transcript of Web Workers - parallel javascript tasks for the masses

  • 8/14/2019 Web Workers - parallel javascript tasks for the masses

    1/1

    WEB WORKERSPARALLEL JAVASCRIPT TASKS FOR THE MASSESBy Adnan osman i

    Ive been looking at some of the cool new features being added to popular web browserslately and I thought Id talk about Web workers this week. Spawned fom the Google Gearsteams WorkerPool Api [1], Web workers allow your web pages to run javascript asbackground threads. Once youve created a worker you can communicate with them by simplyposting messages to an event handler thats been specified by the creating object. The realpower behind Web workers is that you can perform certain tasks without interfering with theuser interface at all - this means fewer pages "hanging" when youre executing a ton of Ajaxreqests through your UI as web worker threads are able to use XMLHttpRequest.

    At the moment when you want to achieve any real computation using JavaScript you need tosplit up your tasks into chunks and then split their execution apart using timers - this can bevery cumbersome and doesnt allow any of them to be run in parallel. A Worker is very easy tocreate and using the line "new Worker("script.js");" should be enough to get your scriptrunning in the background without any problems. Sound good so far? Although workers are agreat addition , there a few caveats to using them. One of the biggest is that they dont havedirect access to the DOM (at least not at the moment) - the main functions you do haveaccess to are setInterval, setTimeout and as previously mentioned - the XMLHttpRequest.The way workers should be used effectively are as follows: Create a new worker which youthen assign an onmessage function to. This is the message received from the client whichcan itself use the postMessage API to post a message back saying that something has been

    done or that an event has been executed. This model has been embraced for a few differentreasons - It allows the worker threads to run securely as they cant affect the parent scriptsthat ran them. Secondly, as the DOM is locked down from more threads, web browserdevelopers dont have to worry about managing the logistics surrounding large pools ofthreads running around crazily. To summarize all of this, Web workers let us take ourJavaScript processed and highly parallelize them. Dont worry about backwards compatability- for browsers that dont support workers, your browser will simply degrade to executing tasksin sequence but for those that do..you can expect a smoother, faster user experience.To get started using Web Workers, feel free to check out the Mozilla page on Web Workersfor FireFox 3.5 below [2] or Ajaxians post on Workers with another code example[3]. Youshould also find support for workers in Safari 4 and the Chromium nightly-builds. Why not trythem out today? :)

    References

    1. http://code.google.com/apis/gears/api_workerpool.html2. https://developer.mozilla.org/En/Using_DOM_workers3. http://ajaxian.com/archives/web-workers-update-for-firefox-31