have concurrency on even a single thread. Parallelism: multiple tasks run at the same time True parallelism is not possible without multiple concurrently active execution contexts, and can be extremely fragile in code written for Web applications. ≠
thread to respond to user input, resulting in a snappier experience. Additional executors might also be used to wrap otherwise synchronous operations, as long as the underlying platform allows. Better Utilisation of Resources Additional execution contexts can better utilise available cores when there is a non- trivial amount of work to be done on the client.
the work cannot be parallelised. Essentially true for things that will be shown to the end user (in the UI). Breaking work down into multiple pieces might introduce additional overhead. This results in a net increase of processing time and could make things worse!
execution context) is responsible for managing the Control Flow. It can spawn multiple execution contexts, or just schedule work to be done. It has to aggregate work results and present these to the end user.
They need to be seeded with work to be done, and they need to convey the results back. This is usually done with the Channel Messaging API (postMessage calls and message events).
no longer wants to do something, in-progress work can be cancelled. Isolation & Handling of Errors Instead of doing everything in a single Worker, consider a supervision tree, which allows cleaner code, partial failures/restarts and general isolation of failures.
Problem should be dealt with server-side? Can the Problem actually be dealt with concurrently? Amdahl’s Law, etc. — maybe only parts of the Problem can be solved concurrently? Additional complexity needs to be justified.
of both execution and maintenance overhead. Use Promises to manage control flow. Resolve the appropriate Promise in message event handlers, to avoid nested callbacks or other complications. Allows maintenance of a single-threaded illusion — part affordance and part burden.
What’s sent first will be received first. Busy workers cause buildup of messages. Web Workers are not threads. You can create many, many more Workers than the number of threads that a healthy system is capable to support. System stability may suffer, though, and additional Workers might block/fail on creation since Workers are implemented with Threads which may be subject to quota.
parallelisation You need to spend time setting up and tearing down contexts, aggregating results, and so on. There is also a mental cost to parallelisation At least in Web applications, parallelisation is not straightforward and usually carry quite a big maintenance burden.
same context. Unlike Web Workers, there is no true isolation between the host document and its iFrames. Chrome’s ongoing work on top-level document isolation is supposed to help with this though. Cancelling something is as important as running it A Web application that can’t regulate itself is an app that goes “Aw Snap”.
parallelise There is only one compositor per document at this time. Even in case of each iFrame being driven from a separate process, composition is non-trivial. Some things can’t be poly-filled You can fake the illusion of a feature, like Offscreen Canvas, but reality catches up with you, eventually. Sometimes it is never as good as native.
iFrames, don’t draw anything Even the simplest thing can slow down in great numbers. Don’t use iFrames for concurrency They are not isolated from each other. You can use multiple windows, though, as long as the browser does not decide to offload or throttle background contexts.
API. The Chromium Projects Chromium Security — Site Isolation. Chromium Design Document — Site Isolation. Blink Workers. WHATWG Living Standard for Web Workers.