Degrading gracefully with Web Workers

Question

So I'm starting to hear more and more about Web Workers. I think it's absolutely fantastic, but the question I haven't seen anyone really tackle so far is how to support older browsers that do not yet have support for the new technology.

The only solution I've been able to come up with so far is to make some sort of wrapper around the web worker functionality that would fall back to some crazy timer based solution that would simulate multi-threaded execution.

But even in that case, how does one detect whether web workers is a supported feature of the browser currently executing the javascript?

Thanks!

Answer 1

This is the age-old problem of web development: what to do about browsers that don't support what you need. Currently, I only advocate using Web Workers for complex, long-running tasks that can be broken up, and for some reason, can't be done server-side. This way, if you don't have Web Workers, you simply wait longer. Otherwise, you would have to make a mess of your code with wrappers and whatnot that you'll try to avoid later. My degradation strategy happens as soon as the page is loaded.

onload function pseudocode:

if( window.Worker /*check for support*/ )
    someObject.myFunction = function() { /*algorithm that uses Web Workers*/ }
else
    someObject.myFunction = function() { /* sad face */ }

You still have to write the algorithm twice, but you would have to do that anyway if you want to support browsers without Web Workers. So that brings up an interesting question: is it worth the time (and money) to write something twice, just so it can go a little faster for some people?

Answer 2

After chewing on this for a few days, I ended up writing an article on my blog:
http://codecube.net/2009/07/cross-platform-javascript-webworker/

The idea is that in cases where WebWorker is not defined, there is a wrapper API that just uses built-in techniques. Although the sample in the article is very simple, it does work in all browsers :-)

Answer 3

The Bespin project has (what they call) a facade that allows them to run JavaScript code in Web Workers, Gears Workers and if those are not available in the main thread.

Answer 4

Here's what John Resig said replying to a comment on his blog

I thought about this - but it'll be tricky. You would have to make your processing code use setTimeout/setInterval from the start (this code would end up working in both a worker and on a normal web site). So while the result would be slightly slower for worker-enabled browsers at least it would work in both cases.

Answer 5

I had the funny problem that my task without Web Worker support was too slow in Firefox (unresponsive script), but fast enough in all other modern browsers. With Web Workers it worked in all browsers except Opera (10.50) which doesn't support Web Workers at all, but Opera worked fine without them.

So I wrote a WorkerFacade that uses the Web Worker API when available or fakes the API with some minor additions to the actual Worker JS. You can find WorkerFacade as a gist on GitHub. Worked well for me, might help someone else, too.

Answer 6

You can use Modernizr (http://modernizr.com/download/#-webworkers) to detect if the browser supports webworkers, at which point you then have to have two versions... You can see the browsers with webworkers at http://caniuse.com/webworkers

if(Modernizr.webworkers) 
{} 
else
{}

Answer 7

@geowa4

//globals
var useWorer={}
   ,noWorkerClosure=function(){...}
   ,myWorkerClosure=function(){...}
   ;
function init(){
         if(!!window.Worker){
           noWorkerClosure=null;
           useWorer=new myWorkerClosure();
         }
         else{
           useWorer=new noWorkerClosure();
           myWorkerClosure=null;
         }
}

This way you free some memory onload and you don't need to ask for support each time.