> What browsers are currently supported ?
Since we depend on the `Origin-Agent-Cluster` header being honored by the browser, we are currently limited to Chrome and Edge.
Maybe it's just me, but I'd argue that they should bring compatibility info closer to the demo section. While I do appreciate the mention in the FAQ at the bottom, that is pretty far away from where the demo occurs.
It seems the “threading” mechanism depends on the browser’s own process model? As in, you’ll get another “thread” iff the browser creates a separate process for the cross-origin iframe?
That’s a clever hack where it works. For what it’s worth, it doesn’t seem to work on mobile Safari, at least judging by both examples slowing down at roughly the same rate. In which case, the “parallel” example is very slightly slower, presumably due to marginal overhead of the cross-frame mechanism.
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.
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.
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.
- 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
Even the visualization is drawn in the parallel worker. Which CANNOT be put in a worker. If you wait long enough on the demo page, you will see how much time just redrawing the DOM is consuming.
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?
Readit News
> What browsers are currently supported ? Since we depend on the `Origin-Agent-Cluster` header being honored by the browser, we are currently limited to Chrome and Edge.
I am an FF user myself and super sad to see that :(
It does seem to work in Chrome though.
That’s a clever hack where it works. For what it’s worth, it doesn’t seem to work on mobile Safari, at least judging by both examples slowing down at roughly the same rate. In which case, the “parallel” example is very slightly slower, presumably due to marginal overhead of the cross-frame mechanism.
What kind of DOM computations are so intensive they need to be parallel?
Most intensive computations are done in JS, which is not related to the DOM and can be ran in Web Workers if you need parallel execution.
If they are so heavy, shouldn't the vizualization be WebGL? The DOM is for hierarchical information.
https://web.dev/articles/origin-agent-cluster
This should make self-hosting a bit easier. You can also find the GitHub repository for the (pretty simple) Dockerfile on GitHub[1].
[0] https://hub.docker.com/repository/docker/uninspiredstudioops...
[1] https://github.com/UninspiredStudio/parallel-dom-docker
Edit: Formatting
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?
You could run any number of parallel threads.
This is applicable on both desktop and mobile.