18 ms·
Show HN: Parallel DOM – Upgrade your DOM to be multithreaded
- fabiofzero 2y agoFirefox on M1 Max. After Parallel DOM is slower here.
- ashubham 2y agoThe new browser features used for this project are only supported on Chrome/Edge right now. But FF/Safari have shown positive intent.
- deleted 2y ago[deleted]
- Olesya000 2y ago[dead]
- Olesya000 2y ago[dead]
- xori 2y agoWhy reach for iFrames over other technology like WebWorkers?
- ashubham 2y agoWebWorkers do not have access to DOM.
- xori 2y agoI understand, but things like https://github.com/GoogleChromeLabs/comlink 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.
- ashubham 2y agoI 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.
- SahAssar 2y agoThat's part of the FAQ?
- xori 2y agoI see it now, I don't know how I missed it.
- halyconWays 2y agoWe've strayed too far from God's light. Return to Gopher.
- btown 2y agoCan't call it hypertext without using hyperthreading!
- sakras 2y agoThe demo fell a little flat because the "before parallel DOM" and "after parallel DOM" boxes were almost exactly in sync for me (Firefox, MacOS).
- sottol 2y agoyou have to wait a while until the before box starts to stutter, maybe 30-60 secs.
- kxrm 2y agoYea I did a comparison between Chrome and Firefox as I did not see any difference on Firefox between the panes. It does seem to work in Chrome though.
- lbhdc 2y agoSame here. Pdom stayed at 60fps in chrome, but in firefox it had the same framerate drop off as the sync dom.
- theogravity 2y agoOn an M2 mac using Chrome. The before dropped down to 60 FPS / 10 MB, while the after was 120 FPS / 5 MB.
- ModernCannabist 2y agoIt does say right on the homepage: > 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.
- Nathanba 2y agopretty 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?
- btown 2y agoSee also: https://github.com/krakenjs/zoid 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.
- eyelidlessness 2y agoIt 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.
- ashubham 2y agoYes correct. Safari/FF have shown positive intent to implement this FWIW.
- mr_toad 2y agoThey 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.
- ashubham 2y agoCorrect. A different thread is good too, as long as they are separate resources from the main DOM.
- eacapeisfutuile 2y agoPlease no, this is a solved problem for decades, it will not actually multithread the DOM and more likely just add overhead.
- ashubham 2y agoCan you please put more details. "Origin-Agent-Cluster" frames are actually run in a separate sub process.
- deleted 2y ago[deleted]
- theogravity 2y agoRequesting performance isolation with the Origin-Agent-Cluster header: https://web.dev/articles/origin-agent-cluster https://web.dev/articles/origin-agent-cluster
- XCSme 2y agoI 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.
- candiddevmike 2y agoFurthermore, how can a racey multi threaded DOM end well? AFAIK, most GUI rendering in apps is single threaded.
- ashubham 2y agoI 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.
- dgfitz 2y agoI 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.
- ashubham 2y agoHeavy 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.
- XCSme 2y ago> Heavy data visualizations, interactive infographics etc If they are so heavy, shouldn't the vizualization be WebGL? The DOM is for hierarchical information.
- 2y ago
- gshklovski 2y agoWorker threads are so frustrating. Good work
- apatheticonion 2y agoIt'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!?
- leptons 2y agoCall me crazy but, WASM won't replace JavaScript. There are so many cases where a simple script will do. Firing up a terminal, writing in another language, compiling and going through the trouble to turn something simple into WASM is actually the crazy thing to do. Also, I am in no way approving of the techniques described in the article.
- chamomeal 2y agoYeah but most big web apps aren’t simple. If wasm ever replaces JS in a significant way, it won’t be replacing simple scripts. It’ll be replacing webpack lol
- explaininjs 2y agoWhy would wasm be needed for build time tools? We already use fast compiled languages for modern webpack replacements (esbuild, swc, Bun :: Go, Rust, Zig), and they don’t use wasm.
- metadaemon 2y agoI do love the idea of a dedicated compiler handling my builds. Even with the most modern build tools today, large web applications can take minutes to build which doesn't include type checking, linting and testing. If you're not prioritizing build times as your app grows, this can quickly balloon.
- leptons 2y ago>It's crazy that people say that WASM won't replace JavaScript. >big web apps So you've defined the goalpost as "big web apps". There are billions more use cases for Javascript than however many "big web apps" might exist. So your phrasing is too broad, maybe consider: >>It's crazy that people say that WASM won't replace JavaScript in big web apps. Nobody's saying that. You are free to use WASM for your "big web app". Nobody and nothing is stopping you. WASM certainly has its place, but it also certainly won't replace JavaScript in most of the places JavaScript is used every day. "Big web apps" are (my guess) maybe 1,000,000 of the 49,501,698 websites that use JavaScript, but it would depend on how you define "big web app" (and I really don't want go down that goal-posting rabbit hole). There are 13.8 million people writing javascript every day, how many of them do you think are working on "big web apps" that actually need WASM? How many of them do you think want to switch to Rust from Javascript? "developers" always seem to think everyone else should be some rockstar 10x programmer, but most use cases for javascript are pretty simple, and yet totally effective for what the requirements typically are.
- raggi 2y agoclassic 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?
- ashubham 2y agoEven 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.
- ks2048 2y agoThe demo is computing prime numbers - what does that have to do with the DOM?
- deleted 2y ago[deleted]
- ashubham 2y agoIt 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
- pragmatic 2y agoI 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?
- ashubham 2y agoThanks for the feedback. You could run any number of parallel threads. This is applicable on both desktop and mobile.
- chrisldgk 2y agoFor 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/parallel-dom/ https://hub.docker.com/repository/docker/uninspiredstudioops... [1] https://github.com/UninspiredStudio/parallel-dom-docker https://github.com/UninspiredStudio/parallel-dom-docker Edit: Formatting