After one state write, what work does a re-run-and-diff runtime do that a fine-grained tracking runtime avoids?

## The same write, two runtimes Take one write: a counter held by a component goes from 4 to 5, and exactly one piece of text on screen shows it. The two dominant models reach the same screen by very different routes, and the difference is entirely in the *discovery* step - what the runtime learns and therefore what it marks. ## What a re-run-and-diff runtime does 1. The setter is called with a new value. It stores it and records that this component is out of date. 2. A scheduler decides when to act, then invokes the component's function again. 3. The function runs **in full**: local variables recomputed, derived values recomputed unless explicitly cached, child elements described again, and a fresh tree-shaped description returned. 4. That description is handed to the next stage, which works out what the change means for the host tree. So the unit of re-execution is the **component function**, and by default a component's re-run implies describing its children too. The cost driver is the size of the re-run subtree and the amount of output it produces - not the size of the actual difference. One character of text changing can still mean re-executing a function that builds hundreds of nodes' worth of description. ## What a fine-grained runtime does 1. The write goes through the value's handle. 2. The handle holds a list of dependents - computations that read it while they were running. 3. Each dependent is marked; when they run, each re-executes **only itself**. The unit of re-execution is the **computation**, which can be as small as one text binding or one attribute expression. A component's setup function typically runs once, at creation, rather than once per update; the parts that re-run are the reactive expressions inside it. Cost scales with dependent count, so a value read in one place costs one re-run however deep the tree is. ## Where the cost actually goes | | Re-run and diff | Fine-grained tracking | |---|---|---| | Unit re-executed | component function | single computation | | Work after one write | proportional to re-run subtree and output | proportional to dependents | | Per-read cost | none | records a dependency edge | | Standing memory | previous output description | dependency graph | | Cost of a deep tree | grows with what is re-run | unchanged | | Mental model | output is a function of inputs, recomputed | a graph of values and reactions | Neither column is free. Re-running pays in wasted re-execution and needs a scheduler, and its users spend real effort telling it to skip work or to cache a derivation. Fine-grained tracking pays a small cost on every read, keeps a graph alive, and has to define an order in which dependents run so that nothing observes a half-updated set of values. It also asks users to keep reads inside tracked scopes - the edge exists only because the read happened where the runtime could see it. ## Why the comparison is not simply "fine-grained is faster" At typical application sizes both are comfortably fast, and the measurable difference usually shows up in the worst case: large lists, wide trees, high-frequency writes such as a drag or an animated value. Re-running also has a genuine simplicity dividend. If output is a function of inputs and the whole function re-runs, then reading the code top to bottom tells you what will be on screen; in a graph model, you reason about which expressions re-ran and in what order, which is a different and sometimes harder question to answer from the source alone. There is also a hybrid direction worth naming: a re-run runtime narrows work with caching and bailouts, while a fine-grained runtime has no need for them because the narrow unit is the default. That is why "how much manual memoisation does this codebase carry?" is often a better question than a benchmark. ## The boundary to keep straight Everything above stops at "this is marked to re-run". What the marked work then does to the host tree - whether an existing node is patched or a new one replaces it - and when the marked work is flushed relative to events belong to later stages. In an interview it pays to state that explicitly, because it shows you are not conflating three different mechanisms under the word "re-render". The answer to this question is about **how much has to be re-executed to find out what changed**, which is decided entirely by the discovery model. ## How to answer it out loud A compact version: "The re-run runtime learns only that a component is stale, so it re-executes that function and produces a full fresh description before anything is compared. The tracking runtime learns exactly which computations read the value, so it re-runs those and nothing else. The first pays in re-execution and buys simplicity; the second pays in per-read bookkeeping and buys precision."