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

I like this proposal a lot more after sitting with it a bit longer. At first I was thinking this was about library code managing the moving and managing of ranges of elements, but this is more. This helps with giving the users of said libraries the equivalent of React JSX Fragments. Like consider:

```js
const div = html`<div></div>`
const frag = html`<div></div><div></div>`

// further down
const view = html`<div>${ condition ? div : frag }</div>`
```
I had a user ask why the div always worked, but the second time they attached the fragment why did it not render anything. The answer of course was that `div.appendChild(frag)` removed the childNodes from the fragment so on the second attach there were no childNodes to append. Now one could argue I could make frag an array (slice the childNodes) but that doesn't handle dynamic top level changes in the fragment. 

In a library based on KVO Observables top level dynamic updates that execute independently of top down reconciliation having a standardized DOM API that works the same whether attached or not is hugely helpful in this scenarios.

Beyond that all these libraries have a similar concept. Being just a DOM node works very consistently with the whole
```jsx
// tagged templates
const el = html`______` //or
// jsx
const el = <______ />
```
way of approaching rendering which has been gaining steam (looking at the API's on the top end of performance in the [JS Frameworks Benchmark](https://github.com/krausest/js-framework-benchmark)). More and more non-virtual DOM libraries are picking this approach and showing it is performant.

-- 
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/736#issuecomment-507939907