I understand, but things like https://github.com/GoogleChromeLabs/comlink enable it. Similar to how iFrames don't have access to their parent page you need a facilitator. My question is why not use a js facilitator that could work in all browsers, rather than just Chrome.

I find it an interesting choice that the author decided to invest in new iFrame technology rather than existing multi-thread technology in the browser.

The demo is computing prime numbers - what does that have to do with the DOM?

I think you’re burying the lede here.

It looks like you have the ability to run an isolated portion of the dom on another thread and you can communicate with it with this library? Am I close?

I think more examples could help. Could you have 2-3 real time analytics viz/charts running in 2-3 different threads? Is this mostly for desktop or does mobile benefit also?

What are "third party plugins" in this context?

> Heavy data visualizations, interactive infographics etc

If they are so heavy, shouldn't the vizualization be WebGL? The DOM is for hierarchical information.

Sure, let's take 80% of market share and track users for our own benefits. Standards.

They say they’re looking at implementing origin-agent-cluster. That doesn’t mean they’ll change their internal process model. There is no specification for how a browser runs processes. Even Chrome might decide to use threads instead of processes for iframes.

classic web engineering demo:

  - small well contained math operation that could be put in a worker
  - instead of putting that in a worker, startup a whole parallel page and shuttle messages via ipc for the heaviest part of the process, redoing a lot of the work twice

why are the solutions always backward?