Re: [whatwg/dom] Proposal: a DocumentFragment whose nodes do not get removed once inserted (#736)

rniwa left a comment (whatwg/dom#736)

> Any number of ways, it's been done many times in user space for frameworks to support hydration. If you want something like parts you could render this on the server:

Then what are we adding as new API? It seems like don't need any.

> > Hm... are you imaging that during hydration we'd move the nodes from the regular nodes to this NodeGroup object somehow? It's unclear to me what kind of use of comments and data attributes will address server-side rendering use cases.
> 
> No moving, I'm suggesting that the NodeGroup or Fragment is a pointer to nodes, so you construct that pointer using comment nodes as the separator. This is very similar to how FWs do hydration of fragments currently.

Well, at that point, what is being proposed to be added to the platform? It doesn't sound like anything needs to be added at all since you can just implement all that in user land.

>  > That would be a major departure from the current model of DOM nodes, and it would pose major implementation challenges.
> 
> Can you speak to what those challenges would be. It doesn't seem that far of a departure to say that the group doesn't act as a parent node.

DOM nodes are implemented as a C++ object in most browser engines. They have a single pointer back to its parent node. Having a single node having two different parent nodes (NodeGroup and its regular parent) is a very novel concept. Since browser engine internals are written with the assumption that each node belongs to at most one location in DOM, changing that semantics would require quite a bit of refactoring / rewrite. I'm not at all convinced that anything proposed in this issue is anywhere near good enough to justify that kind of undertaking.

> > This is why NodeGroup being a part of DOM tree is an appealing alternative. Then you can easily insert an empty fragment / group. I'm not necessarily advocating for one approach or the other but being able to handle empty group case without much complexity seems important.
> 
> What is the difference between an empty group being represented by 2 start and end comments vs new special start and end tags? The comment approach seems much more backward compat friendly and easier to polyfill for. I don't even think it would be possible to polyfill a `NodeGroup` that was part of the DOM tree, which would make adoption take longer.

I don't think I've ever suggested introducing new tags in lieu of comment nodes? On the other hand, if a feature can be completely polyfilled, it lowers the benefit of implementing it natively in Web browsers. If people are using comment nodes to implement these semantics fine, what is the motivation for adding anything natively to the web platform? Since every new feature has a corresponding cost to maintain, we better have a good reason to add any new feature to the platform.

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

Message ID: <whatwg/dom/issues/736/2759898130@github.com>