JavaScript Web Workers: Support & Testing The Browser

In case you’re not yet familiar, the JavaScript Web Workers API is a feature that facilitates the execution of scripts in an independent background process, away from any UI related logic. It should be assumed that the Worker’s life-cycle is the same as the application that called it, as it comes with start-up and instance memory performance costs. These costs are actually quite minimal when compared to the power that a single Worker thread provides:

• Independent JavaScript execution environment (also known as “worker process”) running parallel to your the window (also known as the “renderer process”)
• Concurrent, parallel execution
• Non-blocking execution (the worker itself is asynchronous)
• Take full advantage of multi-core machines
• With SharedWorkers, the processing power can be shared across tabs and windows

Some additional information about security, originally published at the Mozilla Developer Center…

The Worker interface spawns real OS-level threads, and concurrency can cause interesting effects in your code if you aren’t careful. However, in the case of web workers, the carefully controlled communication points with other threads means that it’s actually very hard to cause concurrency problems. There’s no access to non-thread safe components or the DOM and you have to pass specific data in and out of a thread through serialized objects. So you have to work really hard to cause problems in your code.

All of that is really meant to serve as a summary or primer for the release of my collection of Web Worker unit tests. These tests are meant to test the browser itself for support of Web Workers:

Web Worker Support

This is not meant to be a complete and definitive list – I would like to extend the opportunity for contribution to this document to the entire JavaScript community – save your suggested tests to Gists on Github and leave links to your gists in the comments.