A widget refreshes its list by assigning container.innerHTML = newMarkup on every update. What starts breaking as the widget grows, and how do you reason about it?

## What the assignment actually does `container.innerHTML = markup` runs two steps. First it parses the string into a document fragment. Then it removes every existing child of `container` and inserts the fragment's nodes in their place. The old nodes are not updated, reused, or diffed against the new ones — they are detached and, once nothing references them, collected. Even if the new markup is byte-for-byte identical to the old, you get an entirely new set of node objects. That is the whole mechanism. Every symptom below is a consequence of it. ## What lives on nodes rather than in markup A node object carries state that its HTML serialization does not express. Replace the node and the state is gone: - **Event listeners** added with `addEventListener`. They are attached to the node object; the serialized markup contains no trace of them. This produces the signature bug: the button works, the list refreshes, the button is dead. - **Current form state.** A typed value lives in the control's value property, not in the `value` attribute, so the serializer never writes it. Same for a checkbox's checkedness against the `checked` attribute, and for which `<option>` is currently selected. - **Focus.** If the focused element is removed, focus falls back to the body. A widget that rebuilds on every keystroke will yank the caret out of the field on the first character. - **Selection and caret position** inside text, for the same reason. - **Scroll position** of any scrollable descendant. - **Your own references.** Variables holding elements from the old subtree still work, but they now point at detached nodes: reads succeed, writes succeed, and nothing appears on screen. This is a particularly slippery failure because nothing throws. ```js const box = document.createElement('div'); box.innerHTML = '<input><button>go</button>'; const input = box.querySelector('input'); input.value = 'typed'; box.querySelector('button').addEventListener('click', () => console.log('hi')); box.innerHTML += '<span>extra</span>'; box.querySelector('input') === input; // false — a different node box.querySelector('input').value; // "" — the typed text is gone // the click listener died with the discarded button ``` ## Why += is the worst version `el.innerHTML += x` desugars to `el.innerHTML = el.innerHTML + x`. The getter serializes the *entire current subtree* into a string; the setter then re-parses the whole thing. So appending one row rebuilds every row, and the amount of serializing and parsing grows with the size of the container rather than the size of the addition. Worse, that round-trip through text is lossy in exactly the ways listed above, so an operation that reads like "add one item" silently resets everything already there. `insertAdjacentHTML('beforeend', markup)` is the direct replacement: it parses only the new string and inserts the result next to the existing children without touching them. Positions are `'beforebegin'`, `'afterbegin'`, `'beforeend'`, `'afterend'`. It carries the same markup-sink caution as `innerHTML` — never feed it untrusted strings. ## Diagnosing it in the wild The bug report rarely says "innerHTML". It says one of these: - a control works the first time and never again; - the search field loses what the user typed, or loses focus, on every result update; - a checkbox visibly resets after an unrelated part of the panel refreshes; - a list scrolls back to the top whenever anything changes. When you see any of those, look for a wholesale write to `innerHTML` on an ancestor of the affected element. Confirming it is quick: hold a reference to a node before the refresh and check identity afterwards, or log `document.activeElement` before and after. ## The judgment to apply The question is not "is `innerHTML` bad" — it is "is this subtree genuinely disposable". Wholesale replacement is fine for a region that holds no interactive state, no listeners you attached individually, and no references you kept: a purely presentational panel rendered from data, thrown away and redrawn. The moment the region contains form controls the user interacts with, or you are holding node references across the refresh, the cost of the shortcut is state loss, and the fix is to narrow the write. Change only what changed: assign `textContent` on the one node whose text differs, flip a property on the one control, add the one new row with `insertAdjacentHTML` rather than re-emitting all of them. Narrower writes also mean less markup being generated from data, which shrinks the surface where an untrusted string could reach a markup sink at all.