Opinion about synchronous requests in web workers

I just wanted to add a note (that is too long for a comment) that the limit of ~60 web workers mentioned in @tiffon's answer doesn't appear to exist in Chromium anymore. I can create 500 workers in Chrome like this with no errors/crashes:

let workers = [];
for(let i = 0; i < 500; i++) {
  let worker = new Worker(URL.createObjectURL(new Blob([`console.log('cool${i}')`])));
  worker.postMessage({});
  workers.push(worker);
}
await new Promise(r => setTimeout(r, 15000));
for(let i = 0; i < workers.length; i++) {
  workers[i].terminate();
}

Though, it's hard to imagine a situation where hundreds of workers would be appropriate, given core counts don't currently go higher than around 64.

I don't have hard facts, but since you asked for opinions... :)

There is a telling issue in Chrome: Too many Web Workers can cause a silent crash (caps ~60-100, according to this bug report). The general problem is Web Workers are resource intensive, at least with v8.

Assuming you're going to end up making multiple HTTP calls, if you're doing synchronous HTTP calls in a Web Worker:

• In a sense, you're trading asynchronous HTTP calls for asynchronous Web Workers, which will only be adding another intermediary into the mix and you still have to manage things asynchronously.
• If you go the simpler and more resource efficient route and only use one Web Worker you'll spend a lot of time waiting for it to give you responses.
• If, on the other hand, you use multiple Web Workers you will likely need to keep track of which one is free, which one is busy, etc., in which case you will be creating a home-grown scheduler instead of using what comes baked into the browser.
• Finally, Web Workers are expensive (apparently), and you might end up creating multiple Web Workers just so they can sit around and wait for an HTTP call to finish.

I do not consider myself an expert on the matter, so please take this for what it's worth.

Update: Adding some pros / cons for various scenarios.

Some pros / cons that come to mind when choosing between making synchronous and asynchronous HTTP calls when using a Web Worker:

• Generally, synchronous requests will be easier to write and will result in code that is easy to follow. A downside of synchronous requests is they might encourage writing long functions that should be carved out into separate, smaller functions.
• If you're making a single call, there is no difference in the time it takes to finish between the two methods and synchronous is better because it's a bit simpler. I say it's only a bit simpler because a single asynch call with one callback listener is really rather simple.
• If you're making multiple calls that have to happen in a specific sequence, like loading a user's profile data and then getting the local weather based on their address, synchronous calls will be better because it will be easier to write and a lot easier to read. The main thing about reading it is the sequential dependencies in the calls will be clearly outlined by the choice of making the calls synchronously and their order in the function. The more calls there are, the more this will matter. If there are many calls, the difference in complexity is likely to be drastic.
• If you have to make multiple calls that do not need to happen in any specific order, then asynchronous requests are better because the overall process is likely to be orders of magnitude faster than with synchronous requests. The more calls you're making or the slower the connection, the more significant the difference in total elapsed time will be; this difference will grow very quickly (exponentially?). From the perspective of someone reading the code, I think using synchronous requests, in this situation, would be somewhat misleading as it would suggest there is a sequential nature to the calls even though there is not. From the perspective of writing a series of asynch requests that are not dependent on each other, it shouldn't be too bad because you just setup a counter, make all the calls, increment the counter in each of the callbacks and you're finished when the counter equals the number of calls you made.

Update: @rbrundritt makes a very interesting and relevant observation in a comment on this answer:

One thing I found working with web workers is that they appear to each gain their own http limit. Browsers limit the number of concurrent http requests to around 8 or 12 depending on the browser before throttling, which can be a bottle neck if you have a lot of requests to process. I've found that if I pass my requests web workers, each can do 8 to 12 concurrent requests before they start throttling. This can be a huge benefit for some apps.

@rbrundritt