Re: [WICG/webcomponents] Idea: A tree-aware task scheduler (Issue #1055)

fwiw, out of some historical curiosity and some different ideas in the area from the past: I once floated an idea to some Chrome colleagues to add distinct async read/write phases to the DOM. This was based on the Fast DOM approach and Dimitri Glazkov's nope.js (which threw on sync layout flushing APIs): you wait for the whole DOM to enter a read or write phase, then perform whatever operations you need for that phase.

I've lost access to the internal doc where I wrote it up, but this is a extremely brief description and prototype of the idea: https://github.com/PolymerLabs/async-dom

At the time this was a slightly popular concept as a way to fix DOM performance footguns.

Looking back, I think the scheduler idea is much better, because it's much more explicit.

Instead of waiting for the DOM to get in some state, you're telling the DOM that you want to do _this task_ when the DOM is ready for it. That's what allows the DOM to do tree-order scheduling and potentially sooner-than-microtask timing, flushing the queue, introspection, etc. Also, `queueDOMUpdate()` doesn't necessarily need to return a Promise, which would eliminate the allocations.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1055#issuecomment-2079933961
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1055/2079933961@github.com>