I'm wondering the same thing. It seems like it'll primarily be used as a bandaid for poorly written applications to run slightly less slowly. Lovely, now some garbage page can hog more of my CPU, this is exactly what I wanted.

Heavy data visualizations, interactive infographics etc. Also, if your app has the capability to run third party plugins you generally want to run it in a separate context for security reasons. With PDom, you also isolate yourself from the perf implication the 3rd pary code may have.

> Heavy data visualizations, interactive infographics etc

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

There are no good webGL charting libraries. SVG is the gold standard as the fidelity is way higher. No one wants to look at charts which look like science experiments.

What are "third party plugins" in this context?

Let's say your application supports a plugin marketplace where community can build plugins for your app.

For eg, a testrail plugin for JIRA or a diagramming plugin on Google Docs.

You would want to run these plugins in their own DOM so that they don't accidentally slow down the main app.

Furthermore, how can a racey multi threaded DOM end well? AFAIK, most GUI rendering in apps is single threaded.

I assume you meant "race conditions" when you say "racey multithreaded DOM". The multithreaded part here is still isolated in its own context (iFrame), you should never have a race condition with your main DOM thread.

I don’t know if I agree with that last bit. “Don’t do work on the gui thread” is basically a mantra. It’s also not very effective to show a progress bar in a gui unless you don’t mind the rest of the gui to be unresponsive.