[HN Gopher] Show HN: Parallel DOM - Upgrade your DOM to be multi...
___________________________________________________________________
Show HN: Parallel DOM - Upgrade your DOM to be multithreaded
Author : ashubham
Score : 34 points
Date : 2024-07-09 20:36 UTC (2 hours ago)
(HTM) web link (www.pdom.dev)
(TXT) w3m dump (www.pdom.dev)
| xori wrote:
| Why reach for iFrames over other technology like WebWorkers?
| ashubham wrote:
| WebWorkers do not have access to DOM.
| SahAssar wrote:
| That's part of the FAQ?
| halyconWays wrote:
| We've strayed too far from God's light. Return to Gopher.
| btown wrote:
| Can't call it hypertext without using hyperthreading!
| sakras wrote:
| 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).
| sottol wrote:
| you have to wait a while until the before box starts to
| stutter, maybe 30-60 secs.
| kxrm wrote:
| Yea 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 wrote:
| Same here. Pdom stayed at 60fps in chrome, but in firefox it
| had the same framerate drop off as the sync dom.
| theogravity wrote:
| On an M2 mac using Chrome. The before dropped down to 60 FPS /
| 10 MB, while the after was 120 FPS / 5 MB.
| ModernCannabist wrote:
| It 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 wrote:
| 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?
| btown wrote:
| 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.
| fabiofzero wrote:
| Firefox on M1 Max. After Parallel DOM is slower here.
| eyelidlessness wrote:
| 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.
| eacapeisfutuile wrote:
| Please no, this is a solved problem for decades, it will not
| actually multithread the DOM and more likely just add overhead.
| theogravity wrote:
| Requesting performance isolation with the Origin-Agent-Cluster
| header:
|
| https://web.dev/articles/origin-agent-cluster
___________________________________________________________________
(page generated 2024-07-09 23:00 UTC)