Post

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…

github.comMSEdgeExplainers/EventPhases/explainer.md at main · MicrosoftEdge/MSEdgeExplainersHome for explainer documents originated by the Microsoft Edge team - MicrosoftEdge/MSEdgeExplainers

13 reposts57 likes

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!

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?

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.

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.

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).

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