Creating and Moving Nodes

## What a DocumentFragment actually is A `DocumentFragment` is a node type whose only job is to hold other nodes temporarily. Create one with `document.createDocumentFragment()` or `new DocumentFragment()`. Two properties define it: - It has **no parent** and belongs to no rendered tree, so nothing inside it is displayed, styled, measured or matched by selectors run on `document`. - It is **transparent to insertion**: when you insert a fragment anywhere, the DOM's insertion algorithm has a special case — it inserts the fragment's children and never the fragment node itself. That second point is the one interviewers probe. ## The build-then-insert pattern ```js const frag = document.createDocumentFragment(); for (const item of items) { const li = document.createElement('li'); li.textContent = item.label; frag.append(li); } list.append(frag); // one insertion into the live tree console.log(frag.childNodes.length); // 0 ``` Every `frag.append(li)` mutates a detached object that no rendering machinery is watching. Only the final `list.append(frag)` touches the document, and it moves all 500 children across in one operation. ## Why the fragment ends up empty The rule is the same one that makes ordinary insertion a move rather than a copy: a node has at most one parent, so moving the children into `list` removes them from `frag`. Combined with the fragment's transparency, this means: - `frag.parentNode` is always `null`, before and after. - `list.lastElementChild` is the last `<li>`, not the fragment. - The fragment is reusable but **empty** — a second `list.append(frag)` inserts nothing, silently. Code that builds a fragment once and appends it in two places is a real bug: the second target gets nothing. If you need the same content twice, clone before inserting: `list.append(frag.cloneNode(true))` inserts a copy and leaves the original fragment populated. ## What you can do with a fragment while building A fragment implements `ParentNode`, so `append`, `prepend`, `replaceChildren`, `children`, `firstElementChild`, `querySelector` and `querySelectorAll` all work on it. It also implements `NonElementParentNode`, so `frag.getElementById('x')` works. What it is *not* is an `Element`: it has no tag name, no attributes, and no `innerHTML` property, so you cannot build one by assigning markup to it. Being able to query a detached subtree is genuinely useful — you can wire up structure, look up nodes inside it, and attach listeners before anything is visible to the user. ## Where the batching argument stands today The folklore claim is that appending 500 nodes one at a time causes 500 layout passes. That was never quite how browsers behave, and modern engines defer and coalesce work aggressively. What is unambiguously true is the DOM-level fact: with a fragment, the live tree is structurally modified once, and mutation observers and other machinery watching the document see a single childList record instead of 500. It is also worth knowing the alternative. Because `append` is variadic, this achieves the same single insertion without a fragment: ```js const nodes = items.map(makeRow); list.append(...nodes); ``` So the honest answer to "why a fragment" is not only speed. A fragment is the right tool when you want to **hold** a detached subtree — build it in one function, return it, query it, pass it between modules, insert it later — or when you are draining nodes out of the document and want somewhere to park them. ## Other places fragments appear Fragments are not just something you construct by hand; several APIs hand you one. Understanding the transparency rule is what makes those APIs behave predictably: whatever hands you a fragment, inserting it deposits its children and leaves the fragment hollow. ## The mental model Think of a fragment as a shopping bag rather than a box. You carry the items in the bag, but when you insert the bag into the tree the *items* go in and the bag stays behind — empty, still yours, still reusable if you refill it.