Re: [whatwg/dom] Proposal: DOMChangeList (#270)

> To make sure I am clear, the point here is that by proposing a separate API surface, we could exclude any operations that would be invalid coming from a Worker because they depend on a relayout on the UI thread? 

More than that, the API gives developers a way to express a batch of DOM operations that by definition cannot accidentally interleave accesses that would force a layout flush. Because the batch is applied without interleaving JavaScript code, the API creates a natural staging between blocks of pure DOM mutation and blocks of CSS-dependent changes.

> It sounds like this point is still a bit unclear. 1) this proposal may require more bindings? 2) it's unclear if reducing bindings would lead to significant performance improvements.

If it's impossible to implement the `NodeToken` type without introducing new heap allocated JavaScript object, I definitely want to know that. Is that what you're saying?

> This benefit could be achieved through any asyncAppend style API.

As long as the only mutations we're talking about are various forms of `append`. Do you envision things like `asyncNodeValue =`, `asyncSetAttribute`, etc. Or is there a reason that only async versions of append operations would be necessary?

> This benefit could be achieved through any WorkerNode style API.

I really want to see a detailed version of a WorkerNode-style proposal. I must have missed previous discussions fleshing it out; it's very hard for me to compare the impact of such a proposal against this proposal. I would really love a pointer to more details that could help me do a careful cost accounting of the different proposals.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/270#issuecomment-227308686