How does a renderer's per-node work differ when it creates a first mount, updates a live tree, or claims existing markup?

## One description, three modes A renderer's job is to make the host agree with a description. What that costs depends entirely on what is already there. - **Create** (first mount of a tree or subtree): nothing exists. Every node is constructed, every property written, every node inserted, every listener wired. - **Update** (a tree the runtime already committed): the runtime holds, per position, both the previous description and the concrete host node. It writes the delta only. - **Claim existing** (markup produced elsewhere — a server response, a prerendered file, a cached shell): the nodes exist but the runtime knows nothing about them. It walks them alongside the description, adopts each one as the node for that position, and adds the behaviour the markup cannot carry. ## What each mode actually does per node | Work | Create | Update | Claim existing | |---|---|---|---| | Construct the host node | yes | only for added nodes | no — adopt what is there | | Write attributes, styles, text | all of them | only differing values | skipped; markup is assumed correct | | Insert into the tree | yes | only for added or moved nodes | no | | Attach listeners | yes | only where handlers appeared | yes — this is the bulk of the work | | Populate references, install instance state | yes | keep the existing ones | yes | | Teardown path | none | for removed subtrees | none on the first pass | | Typical failure | none — the tree is authoritative | a stale write or a lost move | a node that does not match the description | ## Why claiming is cheaper, but not cheap Claiming skips node construction and property writes, which is real savings on a large document. It does **not** skip the compute half: the output-producing code still runs in the browser to know what the tree *should* be, instance state still has to be built, and listeners still have to be attached one way or another. That is why a page can be fully painted and still unresponsive — the visible part came free from the markup, the behaviour did not. It also inherits a hard requirement: the client's **first** described output must line up with the markup node for node. In create mode there is nothing to disagree with; in update mode the runtime itself wrote the previous state, so it knows it. In claim mode the previous state was produced by another process, and the runtime is trusting it. ## When the node found does not match A renderer has two responses, and frameworks pick per case: 1. **Patch it** — keep the node, write the value the client computed, and carry on. Cheap, and adequate when only text or an attribute differs. 2. **Discard and rebuild** — drop the node or the whole subtree and re-run in create mode for that region. Necessary when the *structure* differs, because walking in lockstep is no longer possible. The second is where the cost shows: the server's work for that region is thrown away, and if the mismatch sits near the root, a large part of the page is rebuilt after it was already painted — visible as a flash or a layout shift. ## Modes are per subtree, not per app All three often run in one page's lifetime and even in one pass: - The shell of a page is claimed; a widget that only exists in the browser is created; a later user interaction updates both. - A region can be claimed later than the rest, so an interactive area is wired before the whole document is. - A subtree discarded because of a mismatch switches from claim to create mid-pass. ## Where frameworks differ A runtime that re-runs the output-producing function treats all three modes as variants of the same tree walk, with a flag that says *adopt instead of construct*. A fine-grained runtime has less to do in update mode by construction — each dynamic value already knows its node — but has to locate those nodes when claiming, which is why such runtimes often emit position markers into the markup. A compile-time runtime can generate three specialised code paths, one per mode, and usually produces the smallest claim pass of the three. In every case the conceptual distinction is the same: construct, write-the-delta, or adopt. ## Practical implications - Measure the claim pass separately from paint; they are different problems with different fixes. - Treat a structural mismatch as a bug in the description, not as noise to silence. - Remember that adopting a node does not adopt everything: whatever the markup cannot express — instance state, listeners, references, values a property holds rather than an attribute — is still the client's job on that first pass.