Lots of folks fell for the "DOM is slow" marketing of certain frameworks, but DOM isn't slow. *Uncontrolled style read-back* is. But what if that wasn't a thing? Looking for feedback on a new proposal to control layout thrashing here: github.com/MicrosoftEdge/MS… - ThreadSky

infrequently.org • 27 days ago

Lots of folks fell for the "DOM is slow" marketing of certain frameworks, but DOM isn't slow. *Uncontrolled style read-back* is. But what if that wasn't a thing? Looking for feedback on a new proposal to control layout thrashing here:

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/EventPhases/explainer.md

Comments

zcorpan.bsky.social•27 days ago

I like this. Wonder which pattern is most usable for devs!

infrequently.org•27 days ago

I have the sense that dirty reads whould be allowed in the write phase regardless, but aside from that, no attachment to any style in particular. Hope folks with experience of, e.g., fastdom will weigh in!

kye.boats•27 days ago

Oh…so the whole thing was a giant XY problem. This is all *really* cool and compelling.

mb21.bsky.social•27 days ago

The meta property proposed is nice. But I wonder whether adoption will hit the same problem like CSP meta tags: marketing will insist on their tracking script and we just cannot add the meta tag.
Could we instead opt in an entiry third-party script and all its event handlers into this kind of mode?

infrequently.org•27 days ago

We went through the same problems with MOAR TLS, and it's fair to say that browsers need to make sure the juice is worth the squeeze. Restricting new APIs to only work under this mode is an obvious first step, and one CSP hasn't benefited from.

mb21.bsky.social•27 days ago

Yeah, the stick is always an option. But I meant an attribute like async that web devs can put on the script tag of their third-party scripts they have no control over. It would put the whole script in a dom-read-only mode, or increase the batch size so that the main thread would yield less often.

justinfagnani.com•27 days ago

Have you seen my tree-aware task scheduler idea? I think it could handle the read-after-write cases as well as help ensure coherence and prevent double rendering triggered from shared observable data sources: https://github.com/WICG/webcomponents/issues/1055

infrequently.org•27 days ago

hadn't seen this, but it's conceptually similar to the Promise-based variant in the explainer (assuming sync style readbacks are allowed to be dirty WRT to changes from the start of the callback).

romanliutikov.com•27 days ago

is that mentality still holds true among devs who came to frontend in the past ~5 years? I'm under impression that folks just don't think about it anymore and use frameworks to get their jobs done

infrequently.org•27 days ago

Oh, my sweet summer child.

romanliutikov.com•27 days ago

maybe that's my bubble, where do you get the data from?

infrequently.org•27 days ago

More than 100 partner engagements + reading traces all day from MSFT's flagship web apps. Frameworks have definitively failed to solve this.

yawaramin.bsky.social•27 days ago

What is 'uncontrolled style read-back'? Anywhere I can read about it?

infrequently.org•27 days ago

in the linked Explainer

Comments

Posting Rules

Reply