views:

486

answers:

5

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!

+4  A: 

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( 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?

geowa4
"supportsWebWorkers" ... how would one determine that?
Joel Martinez
@Joel: `if( Worker ) ...`
geowa4
@Joel: edited for clarity
geowa4
You could also do the work on the server if there are no web workers. The advantage would be that server load decreases as users update to better browsers.
Nosredna
A: 

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.

Sam Hasler
+1  A: 

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.

Sam Hasler
+1  A: 

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 :-)

Joel Martinez
A: 

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.

stefanw