Re: [whatwg/dom] Proposal: DOM APIs in web workers? (Issue #1217)

It might be good to contextualise what people want. The ability to de-serialize an HTML string into some kind of object model - and back again - is a hugely different problem than _reifying HTML into a DOM_; as Jake alludes to.

If the ask is "I don't want to bring my own HTML parser when the browser has a perfectly good one outside of Workers" then that closes the scope to a large degree compared to "I want to have the full suite of DOM APIs and shuttle tree fragments between threads". 

What gives me pause about this discussion is; while I don't think people are naive enough to believe the DOM is intentionally blocked from workers, I do think that even people in this thread are failing to correctly grasp (or articulate) exactly what they want and the ramifications of that. I think the reason `DOMParser()` exists, and not `HTMLParser()` is because giving developers a fully reified DOM sits at the very end of a set of steps of taking HTML and turning it into UI, and everything in between is full of so much nuance that it's hard to find one place to settle on.

An HTML parser would alleviate you from some code within workers, and maybe give you a nice performance boost, but I think if people asked for it, they'd end up disappointed with what you get for it (not the DOM). Having a tree of objects that don't ascribe any semantic meaning to each node gives you very little, and once all that data gets sent to the main thread it still needs to be reified into the DOM, and all the thing that your application wants like event listeners. The OP gives some good use cases for having general purpose serialisation but those cases _aren't UI_, they're data transformation. The rest of the thread talks of UI.

On the other hand having an _object model_ that represents HTML requires full reification, which includes all the aforementioned steps and all the decisions about that must come from somewhere - so you're either introducing a fake environment which means whatever DOM you pass back to the main thread needs to effectively go through the same reification all over again (which means reification gets done twice and possibly diverges in each, making a worker DOM not WYSIWYG) _or_ you need to introduce shenanigans tying a worker to a main thread's DOM so you can marshal data back and forth in order to make decisions, at which point you're back to blocking and may as well have done it in the main thread. 

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

Message ID: <whatwg/dom/issues/1217/1659999906@github.com>