Prem Kumar Aparanji 👶🤖🐘May 8
Alex Russell

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

MSEdgeExplainers/EventPhases/explainer.md at main · MicrosoftEdge/MSEdgeExplainers

Home for explainer documents originated by the Microsoft Edge team - MicrosoftEdge/MSEdgeExplainers

GitHub
May 8 at 6:02pmWeb
Show threadshuppyMay 8
@slightlyoff i love the detail you’ve gone into about rendering phases and why it’s hard to avoid doing unnecessary work in complex applications, and i haven’t even gotten to the proposal yet!
Show threadRevin GuillenMay 9

@slightlyoff ooh can’t wait to read this. 😍

Speaking of revisiting received wisdom, I’ve been writing components at work predicated on rejecting frameworks’ whole mental model of tracking data separately, building DOM from it, & trying to hide how DOM actually updates. Instead I’m asserting that your data *are* DOM, and suddenly browser programming is FUN again because now you’re treating the platform as an asset rather than a liability to work around. Now it’s simply “data: display thyself.”

Show threadRevin GuillenMay 9
@slightlyoff being thoughtful about what belongs in light and what belongs in shadow really pays off because it makes browser dev tools so much more useful as a live environment for inspecting and querying your application using standard browser APIs
Show threadFNDMay 9
@revin your ideas are intriguing to me and I wish to read your blog post on the subject
Show threadMx. Aria StewartMay 9
@slightlyoff Oh I like what I'm reading
Show threadniu techMay 11
@slightlyoff It reminds me of #AMP #HTML layout: https://amp.dev/documentation/guides-and-tutorials/learn/amp-html-layout/
AMPHTML Layout System

Overview

Show threadFNDJun 7

@slightlyoff this is very good! indeed, the explanatory parts deserve a URL of their own instead of being buried in a proposal within some GitHub repo...

(I would offer to try my hand at turning this into a blog post, but the combination of barely-adequate understanding, perfectionism and thrashing within my own task queue - as evidenced by this late response - make that a difficult proposition right now)