At our HTML5 HackDay a few weeks ago some of my colleagues tried using web workers to enhance our existing applications. The multi-threading supports provided a significant performance boost to our application.
However, does this mean that web workers are the future of web-app development?
Not so fast. You see the real issue, as it has always been, is browser support. Now support isn’t critical for a lot of HTML5 features, as their functionality can degrade gracefully. Use SVG but degrade to an image. Use local storage but require a constant connection for IE6. Drag and drop files but provide an upload box as well.
This is not possible for web workers. If you want to degrade for older browsers the only thing you can do is create two functions, one for web workers and one for “web slackers”. You can then invoke the correct one based on whether the browser supports web workers or not. So this means that you need to implement the same functionality twice, not to mention you need to remember to maintain both simultaneously. This may be acceptable to you and I admit that it might work for some projects.
But then the question becomes, what is the point in implementing web workers at all? Are you going to say “Well at least it is faster for some of our users”? This means that the application never had a performance problem to begin with, and implementing web workers was nice but unnecessary. A large majority of developers are not going to see this as a worthwhile trade-off.
And while IE9 is great, Microsoft’s decision that it will not support web workers at release means that it will be quite a while before web worker support reaches a level where it will become worth developing for it.
Here’s to the adoption of standard compliant browsers.