Udostępnij za pośrednictwem

Web Workers in IE10: Background JavaScript Makes Web Apps Faster

  • Artykuł

Responsive Web pages result in happier consumers. With Web workers, Web applications are more responsive by offloading complex JavaScript algorithms to run in the background. For example, in this test drive (link), you can see that offloading the work to calculate movement of water in the fountains via Web workers makes the main page more responsive for consumers:

This video shows Web Workers in action in the second IE10 Platform Preview.

For a closer look at the code behind this demo, watch this video.

This example (link) shows the difference in how Web workers help run the ECMAScript test suite much faster. With Web workers, the script on the page runs in parallel without the interruptions of page updates. The difference in elapsed time between today’s programming model and what is possible using Web workers will help the Web get faster.

IE10 Platform Preview 2 includes complete tooling support for Web workers. All of the existing tooling that the F12 developer tools provide for script debugging now works exactly the same for workers, without requiring a simulated environment (e.g. using iframes to emulate a worker). For example, in the image below, the developer paused the script in a worker and can inspect and debug the correct WorkerGlobalScope. We’ll write about Web worker tooling in more detail in an upcoming post.

Screenshot of F12 developer tools at a breakpoint in a web worker with the Watch list open showing 'this' being of type WorkerGlobalScope

IE10 also includes support for channel messaging, so Web workers can work together without the Web page itself needing to coordinate their work. You can try this out in the test drive with the checkbox that says “use lighting effects (requires channel messaging).” Note that this checkbox is disabled in Firefox since that browser does not currently support channel messaging.

Looking at the standards specifications, IE10 Platform Preview 2 includes interoperable support for the W3C Web workers specification along with related features specified in W3C Web messaging specification (channel messaging as discussed above) as well as the HTML5 specification (the structured clone algorithm). Additionally, to help the specification and browser implementations improve, Microsoft has published 50 tests for this specification on the IE testing center.

New Web App Scenarios with Background JavaScript

Web workers enable a host of new programming scenarios for the Web. For example, casual games might choose to run the logic for the "computer player" in a Web worker while users take their turn.

Web workers are a way for a Web page to execute script in the background, in parallel to the page. The main Web page can be much more responsive by separating itself from these long-running and intensive scripts and communicating with them through messages.

Previously, Web applications avoided complex JavaScript algorithms and long-running processing because these activities blocked the Web page from responding to user tasks or updating content on the page. When JavaScript runs too long without yielding, users experience slow response from the Web page and in extreme cases the Web page appears to hang (here’s an example in the context of IE9’s improved hang protection). Web workers enable these complex JavaScript algorithms to run with little impact on the user's experience on the site.

Web workers also enable MVC-style Web page design. MVC designs aim to separate an application's model from its view and controller (user-input). By designing a Web page with all the business logic on a Web worker (the "model"), the Web page can be the view and controller and remain responsive to the user.

While these may look like “threads” for JavaScript, technically there are a few key differences relative to other programming languages. Web workers do not share state with the Web page, and they lack synchronization primitives like locks, critical sections, semaphores, or mutexes. Web workers typically are “long lived,” and start their own event loop and wait for further input once they are started, rather than immediately terminating.

As always, please use feature detection to accommodate browsers (for example on mobile devices) that don’t yet have support:

if (window.Worker) {

      /* Use Web Workers in this browser */

}

Workers and Privacy

Microsoft has communicated privacy concerns (link) about the design of shared workers (link) in the W3C draft specification to the working group, along with a proposal for a way to resolve the issue. Unlike a regular worker that is dedicated to a single page, a shared worker can have different Web pages connect to it. We believe that allowing any two top level domains (e.g. a banking site and a potential attacker, or any site and a potential tracking site) to share a Web worker creates privacy issues. We remain committed to the Security Development Lifecycle (link) and making informed decisions about the security risks consumers face.

As the dialog continues, we look forward to the working group reaching consensus on a design that does a better job respecting consumer privacy.

What workers can do: The Web Worker "Mini-DOM"

The “Mini-DOM” is how Web workers maintain separate state from the Web page. Each worker has its own “Mini-DOM” so it can operate independently of the full Web page and other workers.

The diagram below compares the DOM of a Web page to the Mini-DOM of a worker. Like the main Web page, Web workers have a JavaScript engine with all the typical JavaScript libraries (e.g., Math, Date, Array, etc.).  Unlike the main Web page, Web workers do not have access to anything related to the "view" of the Web page, like the window, document, elements, or attributes. Instead, there is a "worker global scope" object (accessible via the "self" property), which contains a few APIs of the window object (such as "setTimeout" and "postMessage").
Image comparing the execution environment of a web page to that of a web worker with the worker environment does not include window, the document, elements, or attributes

Using Web workers, developers make clear choices in what functionality they offload to maximize computation while retaining Web page responsiveness.

Please download IE10 Platform Preview 2, try out the Web worker demos (link, link), and send us your feedback!

-Travis Leithead
IE Program Manager

Comments

  • Anonymous
    July 01, 2011
    Built in debugging for web workers - so cool!

  • Anonymous
    July 01, 2011
    Obligatory post about how [other browser] had this feature first. In all seriousness though, awesome job guys. Can't wait for Win8/IE10.

  • Anonymous
    July 01, 2011
    That is very good news. I'm looking forward to using web workers in IE10. If you guys include pushState() as well, then I'd be very excited.

  • Anonymous
    July 01, 2011
    The comment has been removed

  • Anonymous
    July 01, 2011
    The comment has been removed

  • Anonymous
    July 01, 2011
    Thanks :)

  • Anonymous
    July 02, 2011
    A thought crossed my mind as I read this. How well can these web workers implement an Actor style of programming? Is the messaging performant and robust enough? Has anybody given that a try?  If so what findings.

  • Anonymous
    July 02, 2011
    Why is he still .jxr (JPEG XR image files), we do support? Please jxr image files.   (Translate)

  • Anonymous
    July 02, 2011
    Windows supports it as a default but uses .hdp which is still a form of JPEG XR except a different file type.

  • Anonymous
    July 02, 2011
    عكس

  • Anonymous
    July 03, 2011
    How can we get how many CPU cores there are directly in JS? This is very useful for determining how many web workers to spawn. navigator.cpuCores ?

  • Anonymous
    July 03, 2011
    The comment has been removed

  • Anonymous
    July 03, 2011
    The comment has been removed

  • Anonymous
    July 03, 2011
    IE team why in IE9 I cannot save this page successfully as a web archive? www.atpworldtour.com/No-1-Novak.aspx It saves but the background doesn't get saved properly. But I can save the same page in Safari (.webarchive) format and it renders successfully. FIX IE's broken MHTML saving.

  • Anonymous
    July 04, 2011
    The comment has been removed

  • Anonymous
    July 04, 2011
    @Matthew - I totally agree.  More importantly some developers will make games/sites that push IE9/IE10 to the max, and users will complain that IE8 doesn't work... support it! its a 50/50.  I love that this stuff is coming, but man we need to deprecate IE6 AND IE7, and in 2012 deprecate IE8.

  • Anonymous
    July 04, 2011
    The comment has been removed

  • Anonymous
    July 04, 2011
    @Leigh is absolutely correct. Microsoft HAS been helping promote modern browser usage as half of all users no longer use IE compared to the 95% market share they had just six or so years ago. Now, with no support for newer versions of IE in the most used versions of Windows, Microsoft helps even more users choose a far, far better browser than anything IE has to offer. It's win, win!

  • Anonymous
    July 05, 2011
    The comment has been removed

  • Anonymous
    July 05, 2011
    The comment has been removed

  • Anonymous
    July 05, 2011
    The comment has been removed

  • Anonymous
    July 05, 2011
    This looks great, but does the IE team intened to follow standards and allow us to use progressive enhancement and not use vendor specific prefixes?  This won't be some -ms: Filter garbage will it?

  • Anonymous
    July 11, 2011
    Such speed, already need to deprecate IE6 and IE7, and in 2012 we need to already deprecate IE8.

  • Anonymous
    July 12, 2011
    I liked your way of presentation. The information you provided is great, Thank you for this, and hope in future you will come with more knowledgeable information. Thanks