ashubham

I don't think Comlink supports DOM as well. It's just syntax sugar over Web workers making them easier to use rather than providing new functionality over them.

It also plots the prime numbers on a visualization which is DOM. You will see over time plotting more points becomes time consuming in the demo

Thanks for the feedback.

You could run any number of parallel threads.

This is applicable on both desktop and mobile.

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.

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.

Use Brave. No tracking, latest features. FF needs to get their shit together honestly.

Correct. A different thread is good too, as long as they are separate resources from the main DOM.

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.

Unfortunately, the new browser features used in the project are currently supported on Chrome/Edge only. But, FF/Safari have shown positive intent.

I am an FF user myself and super sad to see that :(

Can you please put more details. "Origin-Agent-Cluster" frames are actually run in a separate sub process.

The new browser features used for this project are only supported on Chrome/Edge right now. But FF/Safari have shown positive intent.

That initial load lag seems is something non related to this project.

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.