Show HN → Parallel DOM: Upgrade your DOM to be multithreaded

The demo fell a little flat because the "before parallel DOM" and "after parallel DOM" boxes were almost exactly in sync for me (Firefox, MacOS).

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.

I don't understand what it does and why.

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.

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?

Requesting performance isolation with the Origin-Agent-Cluster header:

https://web.dev/articles/origin-agent-cluster

We've strayed too far from God's light. Return to Gopher.

For anyone interested, I made a public Docker Image of the "backend" (which is basically just and index.html and a JS file)[0].

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

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?

It's crazy that people say that WASM won't replace JavaScript. This demonstrates a use case better suited for languages with better threading models than JavaScript.

Feels like the web world is desperately in need of competent threading capabilities. Can I (practically) use Rust or Go in the browser via wasm already!?

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

pretty interesting, Origin-Agent-Cluster only exists on Chrome/Edge so far though and it sounds like it is only intended as a browser hint. From the example I don't quite understand though: Why would the non-parallel version already be so laggy if it runs on the mainthread (1 thread, nothing much else happening on the page) versus the iframe-parallel version which also just gets 1 thread right?

Please no, this is a solved problem for decades, it will not actually multithread the DOM and more likely just add overhead.

See also: https://github.com/krakenjs/zoid which allows you to present a simple interface to sites that want to embed your application and send parameters/register callbacks. All the caveats of frames still apply, of course, and scrolling glitchiness alone is a reason to avoid frames altogether... but if you absolutely need to present your application as a frame, it's a developer-friendly way to do so.

Pdom seems to be a way to do that to yourself, if you can't trust that your content won't cause performance degradations and you absolutely want the context outside that content to stay responsive. I'd only use it, and really any frame, for components where the size is known ahead of time, though; asking a frame to resize itself to fit its contents, when its contents may themselves be resizing to the size of the frame, is a recipe for disaster. Which brings me around to why I try to avoid frames for anything user-facing when at all possible.

Firefox on M1 Max. After Parallel DOM is slower here.

Worker threads are so frustrating. Good work

Why reach for iFrames over other technology like WebWorkers?