12

Web Workers are a technology that I brush up against from time to time, whether as the subject of blog post, or a mention in a presentation.

During a more recent presentation I attended, the speaker said about web workers:

I'm not really sure why they aren't used more.

I realised, having thought about it, that for a technology with such obvious benefits & use cases, web workers seem to have had a fairly slow, or narrow adoption.

Is there some inherent issue with Web workers that makes them less useful? Am I just looking in the wrong places for examples of their use? Or is it that Javascript programmers in general are not particularly used to creating multi-threaded applications.

Community
  • 1
  • 1
Hugo Firth
  • 535
  • 5
  • 13
  • 1
    This is an opinion question, and is thus likely to get closed as off topic for Stackoverflow. It's an interesting question though. – Spudley Oct 29 '13 at 11:19
  • 1
    @Spudley I was afraid of that - I'm interested in people's opinions while it lasts however. – Hugo Firth Oct 29 '13 at 13:30
  • 1
    I think with some rewording it could be made slightly more objective - a question asking for issues with Web Workers that prevent adoption might be broad, but I'd think that it'd be better than the opinion-based question that it currently is. – Qantas 94 Heavy Nov 03 '13 at 00:24

5 Answers5

9

The main reasons they're not used much (in my opinion):

  1. Inertia. They're a relatively new tech, and people haven't taken the time to learn them yet. You went to a talk about it, which means you're ahead of the curve; there's a lot of people out there who haven't even heard the term 'web worker' yet, much less thinking about coding them.

  2. Browser compatibility. Older browsers don't support them. Most people still need to support at least IE8 for their sites, so can't use tech like this yet.

  3. Why bother? The only reason for using a new technology is if it solves a problem or achieves something new. Most sites don't have any real need for web workers. Or even if they do, they don't see the need.

  4. Not shiny enough. The web is a very visual medium, and a lot of the new browser features in the last few years have been very visual. It's easy to persuade someone to try a new feature if it looks good. Web workers are entirely non-visual; the benefits are abstract. Developers may get it, but for most companies the decisions about what to spend time and money on to improve a site are made by non-developers, which makes it harder for web workers to get a look in.

Spudley
  • 166,037
  • 39
  • 233
  • 307
  • Anecdotally I have observed that "new tech" inertia is less common in Web development than other areas. I had meant my question more with Library creators in mind, which simultaneously addresses the 3rd point and renders the 2nd especially important. I suppose [Modernizr](http://modernizr.com/) offers an easy progressive enhancement path? In any case I would think it was a no brainer for things like Game libraries [{1}](http://craftyjs.com/) (with things like pathfinding etc...). Thanks for your feedback! – Hugo Firth Oct 29 '13 at 13:47
8

Since most answers to this question are a few years old, here's my perspective on the current state of things, as of May 2019.

Web Workers are now supported in commonly-targeted browsers, and I'd argue that browser support is no longer a significant obstacle to their use. Despite that, Web Workers still aren't commonly used, and most web developers I interact with don't use them.

Certainly not every website needs to do enough heavy lifting to justify a Web Worker; many websites don't need JavaScript at all. So, I wouldn't expect to see Web Workers in a majority of websites realistically.

But "heavy lifting" is not the only factor in justifying a Web Worker – another is ease of use. Web Workers are a significant challenge to use in many contexts. Note that the Web Worker API involves splitting your build outputs into separate files, or generating that code (e.g. with Data URIs or fn.toString()) at runtime. Web developers use many different build systems, and often have many dependencies in their projects. Configuring the project to create these additional build artifacts with the right dependencies can be difficult, or at least it varies with the build system you have.

Furthermore, this work almost invariably has to be done by each web developer, for each individual project. You could expect much higher Web Worker adoption if WWs were commonly used inside the popular libraries and frameworks that developers already depend on. But they aren't (for API-related reasons, if I had to guess), even for libraries that do a significant amount of synchronous work. And as long as using the main thread is the default, easiest thing to do, that's what most developers will continue to do.

Don McCurdy
  • 10,975
  • 2
  • 37
  • 75
  • 1
    At the end of the day it comes down to the reward isn't worth the cost. With web workers the reward is low for most cases and the complexity cost is high. – bhspencer May 29 '19 at 20:39
  • 1
    To me the bottleneck in adoption is the clunky API. If you could proxy an object into a worker natively (e.g. make this object a worker) then make async calls into it that would solve declaration, communication and possibly bundling. The difference now from a few years ago is that we are attempting more CPU intensive tasks (e.g. image and data processing, including web assembly based tasks), so they just can't live on the UI thread any more. – Christopher Cook May 30 '19 at 11:26
1

my opinion:

  1. They work well only when you need lots of calculation. In other cases, you loose time for sharing resources, merging.
  2. Requires extra coding.
  3. for simple tasks they dont give much benefit and JS usually are not doing lots of calculations.
  4. do not work on every browser, IE8, ie9 do not support it (http://caniuse.com/webworkers)
  5. no DOM access in worker.
  6. Some people just use setTimeout, setInterval instead, BUT in these are not multi threats, only 1 CPU works at same moment.
  7. They do not work well then there is only 1 CPU. Edit: you get benefit from runing processes in background.
  8. sometimes it is difficult to share resources, it takes too much time and in final result is not good.

But when you need to do lots of calculations or run heavy process in background, and you can ignore old browsers, web workers works really well.

ViliusL
  • 4,589
  • 26
  • 28
  • I'm not sure that point 7 is valid. Thread scheduling is still better than nothing, even in the non-deal world of being restricted to a single processor. CPUs are smart :) – Hugo Firth Oct 29 '13 at 13:35
1

Not having most of the APIs supported within workers has put a dampener on their use for many of my projects.

Firefox won't have Websocket support until v35, performance.now in v34, and there's no date for IndexedDB support. Chrome only recently added TextEncoder/Decoder in v38, and can't pass ImageData. Some functionality can be shimmed, but others can't, or are especially painful to work around defeating the purpose.

WebSockets aren't finished.

Adria
  • 8,651
  • 4
  • 37
  • 30
0

Usually, the website with calculations are the Intranet sites. Most of the big companies use Microsoft products and they use IE as browser. It's not easy to have the latest version of IE because upgrade can break many intranet web sites. Currently my company uses IE 9, and they are planning to go IE 10 may be in 2 years.... I have a lot of application which can use Web Workers but I can't because I don't have IE 10...

Hasan Savran
  • 367
  • 2
  • 5