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

> Before I do that, I'd be very interested to read a detailed WorkerNode proposal. Can you give me a pointer so I can do a proper analysis?

Sorry! We've passed ideas in this area back and forth so many times I didn't realize that we've never actually written any of our thoughts down in one place. I threw a rough summary of our thoughts for a `WorkerNode` proposal into a repo so you can take a look:

https://github.com/drufball/worker-node

I think we all agree that there's value in allowing DOM mutation on workers and in allowing a 'smeared' application of layout. One concern we have is that each of these actions is valuable independent (and in sometimes unrelated ways) from each other. Because of this, we're hesitant to bundle both problems into a single, interleaved solution. Right now it feels like we're solving a specific use case (e.g. the Virtual DOM diff + patch model), which may prove unwieldy when people aren't building that precise functionality. For example, when developers just want to smear the layout for a DOM tree they're working with.

Can we separate these into two distinct proposals - one for async application of layout and another for DOM mutations on worker threads? It would be nice to solve each of these problems with their own primitive, making sure to design them such that they can be used in tandem where it makes sense. For example, we can make sure to keep this concept of a DOMChangeList in mind while developing the [async append](https://github.com/drufball/async-append) proposal - which is poorly named since it's about general async DOM mutations, not just append :)

Happy to continue the Worker DOM discussion in a repo that's focused on just that problem. We could use the repo I linked above, or proceed somewhere else!





---
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-227616964