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

rniwa left a comment (whatwg/dom#736)

> > 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.
> 
> I wasn't suggesting that Nodes should have 2 parents, that's precisely why I clarified that parentNode should be null when the nodes in the group are not attached to a parent node in a DOM tree. NodeGroup is never a parent it's more like a Range, and nodes should be able to be part of many groups just like they can be with ranges. But Range isn't a suitable replacements for NodeGroup because it has a different interface than Node and maintains it's contents relative to the parent element, a NodeGroup in contrast would be relative to the start and end Nodes, so when they move the NodeGroup in a sense moves with them.

Okay. In that case, such a proposal is basically indistinguishable from DOM parts. There are some cosmetic differences in terms of API surface but the fundamental capability of both proposals is a Range-like object which allows you to keep inserting or replacing DOM nodes at a specific location in a DOM tree.

> > 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.
> 
> You can but it requires monkey patching Node and Element prototypes, and in doing so reduces overall performance of most DOM operations. Which means rendering libraries are better off using a split code path for handling fragments and nodes. If it were added to the platform then the polyfill would be an acceptable stop gap for browsers that haven't added support.

@mfreed7 did an experiment implementing much of DOM parts API and did exhaustive performance testing. The result is that native DOM parts implementation in Blink was not that much more performant than user-land implementation using comment nodes. The biggest win comes from being able to identify "parts" in the tree quickly but with precompiled template, all the advantages basically went away.

Now, it's possible that someone else can do a similar experiment and find out that native implementation is better after all but so far, we have no evidence of that.

So we're back to square one. We need to ask ourselves why we want to add this API to the platform. And [I mentioned earlier](https://github.com/whatwg/dom/issues/736#issuecomment-2756957945), [@dbaron's summary](https://github.com/whatwg/dom/issues/736#issuecomment-2450228044) provides two distinct design possibilities. The one you're advocating is "Proposal A", which is similar to DOM parts. As far as I can tell, most people on this issue are advocating for "Proposal B", which introduces a new node type that can be inserted into an actual DOM tree.

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

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