fw-03 — Broader Ideas

You have now built an invalidation engine twice

Blink's RuleFeatureSet and your dependency map solve the same problem: an index from "what changed" to "what must be recomputed," with a fallback when precision is impossible.

That equivalence is the payoff of running both tracks. Build systems, query caches, spreadsheet engines, and incremental compilers are all the same machine, and you now have a working mental model of it in 200 lines you wrote yourself.

Glitches are a distributed-systems problem in miniature

The diamond — a → b → d, a → c → d — evaluated in the wrong order produces a transient value that was never consistent. That is a consistency-under-concurrent-update problem, and the fixes (topological order, or laziness) are the same shapes used in dataflow systems and stream processors.

Test for it. Most hand-written reactive systems have this bug and never notice, because the final value is correct.

The observability tax

Automatic tracking removes an authoring burden and adds an observability burden: "why did this run?" needs a graph inspector. Every mature reactive framework ships one, and that is not a coincidence — it is the cost of the architecture.

Weigh this in framework choice explicitly. Debuggability at 3am is a real requirement, and it is where fw-01's explicit model keeps winning long after benchmarks stop mattering.

Next

fw-05 joins reactivity to a renderer; §47 asks you to fill the comparison from your own implementations — including a row for Blink, which is the point.