Performance

Summary #

Measured for 0.3.3 on 11 November 2026 on one machine (an Intel Core i9-9900K Mac, see "Running the benchmarks"), which was doing other work the whole time: every table below that compares two builds therefore carries an A/A control, the same build measured twice in the same session, and a ratio inside the control's range is reported as no difference shown. The tables of 0.3.0 (10 November 2026, the same machine under more load) and the numbers of 0.1.4–0.2.1 (another machine, a 4-core Xeon on Linux) are kept, marked as such, where the history is told; none of them is comparable in milliseconds.

Running the benchmarks #

Each is one command and prints a Markdown table (each builds what it measures first); runtime/bench/README.md describes every tool and its options.

node runtime/bench/run-reactivity.mjs   # [--samples 21] [--warmup 5] [--order roots,vue|vue,roots] [--json out.json]
node runtime/bench/run-reactivity.mjs --libs roots,aa,vue,vue36,alien,preact   # the field: also solid, svelte, reactively, tc39, s, oby
node runtime/bench/run-render.mjs       # [--runs 15] [--warmup 3] [--baseline <checkout>] [--aa] [--json out.json]
node runtime/bench/run-render.mjs --frameworks roots,aa,vanilla,solid,vapor     # the field: also svelte, ivi, inferno, preact, litfix, vue, vanillatpl
node runtime/bench/ab-reactivity.mjs --variants base=<checkout>,new=.,vue=@vue   # [--processes 4]
node runtime/bench/run-patterns.mjs     # [--baseline <checkout>] [--variants roots,aa,base,vue,lc]
node runtime/bench/run-widgets.mjs      # [--baseline <checkout>] [--heap]
node runtime/bench/run-startup.mjs      # [--app examples/todo] [--latency 25 --mbps 10 --gzip]
node runtime/bench/heap-objects.mjs     # live objects per row, by constructor
node runtime/bench/count-dom.mjs        # DOM calls per operation

Run bin/roots install first: Vue, Vite, esbuild and the frameworks and signal libraries of the field are pinned development dependencies in package.json (Vue 3.5.44, the newest version the 7-day cooldown admitted; the tables of 0.1.4–0.2.1 were measured against 3.5.45). Roots itself has no npm dependencies.

Machine for the numbers below: Intel Core i9-9900K @ 3.60 GHz (8 cores, 16 threads), 64 GB, macOS 15.7; Node v24.13.1; Chromium 143.0.7499.4, Firefox 144 and WebKit 26 (Playwright 1.57, headless). The machine was not quiet. For the tables of 0.3.3 (11 November 2026) the 1-minute load average was between 4 and 8 on 16 threads, with other work running next to the benchmarks; for the tables of 0.3.0 (10 November 2026) it was between 5 and 27 (the rendering sessions started at 4.8 and 11.2, the reactivity runs at 27 and 10). Milliseconds of the two dates are not comparable (the build of 0.3.0 creates 1,000 rows in 5.8 ms of script on the later date and in 10.0 ms on the earlier one); each table says which it is. The runs were made one after another, never in parallel (since round nine through a machine-wide lock), with the scripts' defaults unless a table says otherwise. Ratios are more stable than times because all sides are measured interleaved in one session; how stable they were that day is what the A/A columns say.

Earlier machine (0.1.4–0.2.1): Intel Xeon @ 2.10 GHz, 4 cores, 16 GB, Linux; Node v22.23.4; Chromium 153.0.8010.12 (Playwright 1.63, headless), load average 0.2–0.5. Every number in this page that is attributed to rounds one to three comes from there.

The rounds #

Rounds nine and ten were planned from a comparison with other frameworks (the working notes call them rounds six and seven; this page counts on from eight).

Which build is measured #

roots build ships one bundle per entry, tree-shaken and minified, with DEV false (docs/build.md, docs/bundling.md). That is what every timing below loads (the rendering benchmark, startup's roots, patterns, widgets) and what the "as built" size rows describe. Until 0.2.1 the same command shipped one unminified file per module, and those are the files the tables of rounds one to three measured. The tools that attribute work to functions, files or constructors (heap-objects.mjs, count-dom.mjs, profile-render.mjs) build with --no-bundle --no-minify, for the names; the code is the same except that the bundle also removes the if (DEV) branches, which the unbundled modules keep and skip. The reactive core runs in Node, compiled from runtime/reactivity.lisp by the Roots compiler, unbundled and unminified, against @vue/reactivity's production build.

The A/A rule #

A difference between two builds is reported only from a session that also measured the same build twice, interleaved with the others. The control's range is what that session could not resolve; a ratio inside it is "no difference shown", whatever its value. Counts (DOM calls, heap objects, bytes) are exact and need no control.

In Node the order in which the libraries are loaded is part of the result (the one loaded second finds the first one's maps and feedback in the heap; single cases move by several percent with it). A Roots-against-Roots difference of the reactive core is therefore reported only from at least 4 processes, half in each load order, with at most 7 variants per process, as min / median / max of the per-process ratio of medians (ab-reactivity.mjs), and the comparison with Vue is taken in both orders (run-reactivity.mjs --order). Both rules came out of round six, which chased a regression on update 1to1000 and dynamic: deep that turned out to be the load order.

Reactivity #

Method #

runtime/bench/run-reactivity.mjs compiles runtime/reactivity.lisp with the Roots compiler and loads @vue/reactivity's production build (reactivity.cjs.prod.js, what Node's production condition and bundlers pick; the development build is slower). The cases (reactivity-cases.mjs) follow the community js-reactivity-benchmark: the "kairo" cases, cellx, S.js-style create/update cases, random dynamic graphs (pull and effect driven), plus the four original Roots workloads. Each case is written once against the API both libraries share (shallowRef, computed, effect, .value), with no adapter closures in between, and each library gets its own instance of the case module so the cases' inline caches never mix the two libraries' objects.

Per sample: build the graph (untimed), run the timed work, tear the scope down (untimed). Samples alternate between the libraries after warm-up rounds; the heap is collected between cases, not between samples (a forced full GC between samples throws away JIT state and made every sample measure re-optimization: both libraries got ~3× slower and the ranking flipped). The young generation is emptied with a scavenge (gc({ type: "minor" }), which keeps all JIT state) before every sample, outside the timed part. Medians are reported, with half the interquartile range as spread, and every case returns a checksum that must match between the libraries. Vue 3.5 has no public batch, so no case batches writes.

The field (--libs, since round nine) runs the same cases against other signal libraries. A library that does not read and write through .value gets no wrapper object: the runner rewrites the source text of the cases into that library's own calls and loads the copy, so a read in a case is the call a user of that library writes.

What an adapter still adds (lib/signal-libs.mjs): for Preact a call and an array push per effect, to collect the disposers it has no scope for; for Solid an object {get, set} per signal and createRenderEffect as the synchronous effect; for Svelte render_effect and a flushSync() after every write; for reactively a stabilize() after every write; for the polyfill an effect built from a Computed and its own Watcher, flushed after every write; for oby an arrow passing {sync: true}; for alien-signals, Vue 3.6 and S nothing. A process loads at most six libraries, the control included, with Roots and Vue 3.5 in every process, and every group runs once in each load order.

The scavenge dates from round three. Without it, the creation cases measured the sample order: they allocate 3–17 MB per sample, about one young generation per pair of samples, so a scavenge landed at the start of nearly every pair, in the sample of whichever library went first (traced with PerformanceObserver on the earlier machine: Roots 11 of 21 samples with a scavenge, Vue 10; with the order swapped, the medians swapped with it). Round two's creation medians (0.58–0.91×) were that artefact.

dynamic: simple component (pull) reads no leaf: its 20% draw selects none of the ten, so both libraries measure 200,000 writes to signals without subscribers. It keeps its name and its place in the table and in the geometric mean of 30 cases, so that rounds stay comparable; the case it was meant to be is dynamic: simple component, 2 leaves (pull), marked † in the tables and outside that mean. Two more cases outside the mean were added in round nine: create 10k effects declaring onCleanup and 100k writes, 1 effect declaring onCleanup, the first whose effect function declares a parameter. In Roots such an effect gets a registrar of its own (every component watchEffect is one); the other libraries pass nothing, so for them these are plain creation and plain writes.

Results #

Measured on 11 November 2026 on the tree of 0.3.3 (the reactive core is that of 0.3.1), load average 4.4–7.7. Every run went through a machine-wide lock, one at a time.

Against @vue/reactivity 3.5.44, 21 samples after 5 warm-up rounds, a scavenge before each, one process per load order (--order roots,vue and --order vue,roots). Roots loaded and sampled first, the 30 cases every round has measured:

Both load orders, with the three cases added later (†), which are outside the geometric mean:

Geometric mean over the 30 cases: 1.70× with Roots loaded first (≥ 2×: 5; 1–2×: 24; below 1: 1) and 1.72× with Vue loaded first (≥ 2×: 7; 1–2×: 22; below 1: 1). The case below 1 is create 1to1000 in both (0.90× and 0.93×), next to a spread of ±11–26% on Vue's 0.84 ms; this tool has no control. In the six processes of the field runs below, which have one, it reads 0.97 [0.83–1.34] inside a band of 0.87–1.15: level with Vue, not resolved either way (0.3.0: 0.66–0.67×). create 1to1 is 1.11–1.12× here and 1.02 [0.87–1.40] in the six processes: level as well (0.3.0: 0.81–0.82×). The times of the two halves are not comparable with each other; the ratios are.

The field. The same cases against nine more libraries, each with its own notation (see "Method"): three groups of six (the control included, Roots and Vue 3.5 in every group), each group once in each load order, so six processes. Group A (Vue 3.6, alien-signals, Preact signals) 13 samples after 4 warm-up rounds; group C (TC39 polyfill, S, oby) 9 after 3; group B (Solid, Svelte, reactively) 7 after 2. Each cell is the median over the processes of library time / Roots time, then [min–max over the processes]: above 1, Roots is faster. Bold marks the fastest of the row. "A/A band" is the widest range the control (the same Roots build loaded a second time) took in any of the six processes; in group A alone it is 0.94–1.07 or narrower on 28 of the 33 cases and never wider than 0.86–1.17. Versions: @vue/reactivity 3.5.44; Vue 3.6 is 3.6.0-rc.14, a release candidate (its reactivity is a port of alien-signals); alien-signals 3.2.1; @preact/signals-core 1.14.5; solid-js 1.9.18; svelte 5.57.3; @reactively/core 0.0.8; signal-polyfill 0.2.2; S.js 0.4.9; oby 15.1.2.

On the geometric mean of these 30 cases Roots is ahead of every library measured; the nearest is Vue 3.6 rc at 1.13 (both of its processes above 1.1), then Preact signals 1.30, alien-signals 1.36, reactively 1.43, Vue 3.5 1.69, S 2.16, oby 2.92, Solid 4.93, Svelte 6.09 (28 cases), the TC39 polyfill 8.45. Roots has the lowest time in 19 of the 30 rows. It is not the fastest in every case; where a library is ahead by more than its row's band:

Inside the band, so not differences: alien on avoidable propagation (0.94 [0.90–0.99]), Vue 3.6 on unobserved computed chain (0.97 [0.93–1.01]), Preact on avoidable propagation (0.98) and repeated observers (1.00), Svelte on create 100000 signals (1.01), Vue 3.5 on create 1to1000, and reactively by the median on the four creation cases (create+dispose 0.74 [0.65–0.82] in a band of 0.72–1.39, create 1to1 0.86 [0.66–1.05], create 1000to1 0.87 [0.74–0.99], create 1to1000 0.88 [0.84–0.91] in 0.87–1.15). Creating effects that declare onCleanup against Vue 3.5 is not resolved either: 0.87–0.96 in the four processes of groups A and C, 1.18 and 1.34 in the two of group B. Preact signals, Solid, Svelte, S, oby and the polyfill are ahead in no case. The reasons are under "What is still slower".

What the comparison is and is not:

• reactively has no disposal (stop() does nothing), and create 1to1000 and create+dispose time the disposal as well; its numbers there are not comparable. Its lead on wide dense is real.
• Solid and S recompute memos eagerly: dynamic: simple component (pull) (200,000 writes, nothing read) costs them 761× and 311× Roots' time. Without that one case Solid's mean is 4.2 and S's 1.8.
• Svelte does not finish two pull cases (dynamic component (pull), large web app (pull): a derived read outside an effect re-walks everything upstream on every read), so its mean is over 28 cases. Svelte, reactively and the polyfill run their effects outside the write; the adapter flushes after every write, because the cases do not batch. That is the same work per write and not how Svelte is normally used.
• S differs in two checksums (avoidable propagation, mux, ⚠): it has no equality cut-off on computations and runs more effects. Every other library produces Roots' checksums in every case.
• The TC39 polyfill has no effect; the adapter builds one from a Computed and a Watcher each, which is not part of the proposal.
• Groups B and C have few samples and wide bands on the creation cases (up to 0.72–1.39): for their libraries only the large ratios mean something.

Against Roots 0.3.0 (ab-reactivity.mjs, 4 processes, 2 per load order, 11 samples after 3 warm-up rounds; the frozen tree of 0.3.0 as reference). The ratio is the 0.3.0 median over the tree's median per process, min / median / max over the processes; bold where the whole range lies outside the control's range for that case:

Geometric mean over the 30 cases: 1.192 / 1.202 / 1.219, control 0.986 / 0.997 / 1.005. 26 cases are resolved faster, three are not resolved (create 100000 signals, create 1000to1, wide dense), and one is resolved slower: dynamic: simple component (pull), 0.877 / 0.967 / 0.978 against a control of 0.992–1.007 (200,000 writes to refs nobody reads; 2.00 → about 2.07 ms). The gate of 0.3.1 read that case as 0.95–0.99 and not resolved; this session resolves it, at about 3% by the median. An effect that declares onCleanup is created 4.8–4.9× faster and re-run 1.29–1.38× faster.

Memory, exact (bytes per object, round nine's counts): a ref 72 B, a computed 112 B, an effect 96 B (144 B when its function declares onCleanup), a link 80 B. Creating an effect on a shared ref allocated 168 B in 0.3.0 against 208–299 B for alien-signals, Preact signals, Vue 3.5, Vue 3.6, Solid, S and reactively; the effect has grown by 8 B since. A computed nobody observes is in no subscriber list and costs nothing once it is dropped; Vue 3.6 and alien-signals keep 256–280 B per dropped computed alive for as long as its source lives.

Results of 0.3.0 (round eight), for the record #

Measured on 10 November 2026 on the same machine under much more load (load average 27 and 10 at the start of the two runs), so the milliseconds are not comparable with the tables above; the ratios are what that release measured. Against Vue 3.5.44, 21 samples after 5 warm-up rounds, a scavenge before each, one process per load order. Geometric mean 1.39× over 30 cases with Roots loaded first (≥ 2×: 2; 1–2×: 26; slower than Vue: 2, create 1to1 and create 1to1000) and 1.41× with Vue loaded first (≥ 2×: 1; 1–2×: 27; slower: the same 2). The case outside the mean, dynamic: simple component, 2 leaves (pull): 1.23× and 1.22×.

The times of the two halves are not comparable with each other (the processes ran under different load); the ratios are. They agree within ±0.05 on 20 of the 30 cases; triangle (1.21 / 1.52), unobserved computed chain (1.24 / 1.47), update 1to1 (1.35 / 1.58) and 100k writes (1.29 / 1.09) moved most.

Against Roots 0.2.1 and against the tree after round five (ab-reactivity.mjs, 6 processes, 3 per load order, 11 samples after 3 warm-up rounds, load average 6–16). The ratio is the 0.2.1 median over the variant's median per process, above 1 when the variant is faster, as min / median / max over the processes; bold where the whole range lies outside the control's range for that case:

Geometric means over the 31 cases, min / median / max over the processes: the control 0.980 / 1.006 / 1.020; round five 0.995 / 1.014 / 1.021, no difference shown; 0.3.0 1.037 / 1.047 / 1.056, outside the control's range. Five cases are resolved one by one (bold), all of them faster: create+dispose 1.16×, 100k writes 1.16×, broad propagation 1.09×, update 4to1 1.07×, computed chain 1.03×. No case is resolved as slower; the two lowest medians of 0.3.0 are dynamic: deep 0.943 and unobserved computed chain 0.966, both inside their controls. In the same processes Vue 3.5.44 measured 0.732 / 0.744 / 0.758 against 0.2.1 (0.2.1 was 1.34× faster by the median), and was faster than 0.2.1 on create 1to1000 (1.30 / 1.57 / 1.72, resolved) and by the median on create 1to1 (1.11 / 1.27 / 1.51, not resolved against a control of 0.99–1.20).

What made the difference #

Round nine (0.3.1) is the A/B against 0.3.0 above. It came out of the comparison with the field, which showed Vue 3.6, alien-signals and Preact signals ahead of 0.3.0 on 6 to 15 cases each, and it changed no algorithm:

• Strict null tests in the graph functions. link, propagate, the validation walk, trigger, both value getters and the subscribe and unsubscribe paths asked if (link) of variables that are either null or an object. For a truthiness test V8 emits the checks for every kind of value; for link !== null it emits one comparison. The dialect got two predicates for it, (some? x) and (none? x), and every pointer field is initialised to null (a test per class holds that invariant). V8's optimized code for the hot functions is 17–44% smaller (exact); on the prototype this step alone measured 1.15–1.22 on the geometric mean of 11 cases against a control of 1.00–1.03.
• EffectBase assigns its fields in the constructor (the new define-class option (:constructor-fields t)). A derived class whose base has class fields is constructed through a generic stub; one whose constructors only assign is inlined. That was the cost of the two creation cases 0.3.0 listed as slower than Vue 3.5.
• The onCleanup registrar of an effect is a field, where it was an entry in a WeakMap. Only effects whose function declares the parameter have one (every component watchEffect does): creating such an effect is 4–5× faster, a write that re-runs it 1.2–1.4× (the two cases outside the mean, under the tables).
• Measured and dropped, because their gates were not met: two variants of the ref setter (aimed at dynamic: simple component (pull)) and three variants of the validation walk (aimed at avoidable propagation, mux and computed chain). Those four cases are in "What is still slower".

Rounds four to seven changed the core in small ways; their sum is the A/B against 0.2.1 in the tables of 0.3.0 (1.05×). None of the single steps was resolved on its own in the session that made it (the machine was loaded then too), so they are listed with what is exact about them:

• Round seven: a scope stops its effects without iterators (stopOwned: index loops over effects, child scopes and cleanups, where for…of loops allocated an iterator per stopped effect and made stop deoptimize). create+dispose is the case the A/B resolves most clearly.
• Round seven: no variable for "the effect running now". run and rerun saved and restored it around every effect run; the shared onCleanup registrar now goes by the node that is collecting dependencies. That is the write path (100k writes, update 4to1), and it is also the one behaviour change of the core in this release (see "Semantics notes": R106 inside untrack, a computed's getter and a watch getter).
• Round five: EffectBase. Render effects extend an effect class without a scheduler slot and count their runs per render flush with the core's ranIn stamp, so the base effect carries nothing for them.
• Round four: one pass over the flush queue. An effect that ran is stamped with the flush's id (ranIn, a small integer) instead of being marked and cleared in a second loop; the write path checks a transaction depth counter instead of a list.
• Round four: effect(fn, { cleanup: "run" }) promises that fn uses onCleanup only during its run, so the effect hands it the shared registrar without reading fn.length. watch's runner uses it, hence watch, createSelector and the component runtime's watchers; effect(fn) and watchEffect still read fn.length for user functions.
• Round four: a child scope leaves its parent in O(1) (its index, and the last sibling takes the slot), and scopes do not own computeds: a computed leaves its sources' subscriber lists with its last subscriber, so stopping the scope's effects is enough.
• scopeRemoveEffect(scope, effect) is new (round seven), for the component runtime's release of bindings that read nothing reactive.

The earlier rounds, measured on the earlier machine (the numbers in them are that machine's):

Round three (0.1.8), internal only (no behaviour change; 1 test added):

• Effects have 7 fields (were 10). The R102 accounting marks an effect that ran in the flush in progress in its flags and counts only the effects that run again, in a map that exists while some effect re-runs; the queue keeps its entries until the end of the flush, which clears the marks. An effect whose function declares onCleanup keeps its own in a WeakMap. Render effects keep their R220 counters themselves. A create 1to1 sample (10,000 refs and effects, with the case's own arrays and closures) allocates 5.7 MB instead of 6.3 MB (Vue: 7.4 MB).
• Building a graph skips the duplicate search. A new read searches the last 8 links for the same dep (a, b, a); a connected node's links are all in their deps' subscriber lists, so a dep without subscribers cannot have one of them, and the search is skipped. Creating an effect that reads 1,000 fresh refs no longer walks 8 links per read (create 1000to1 0.95× → 1.2×).
• connect/disconnect do not push the computed itself on their stack.
• Alternating reads are found without a call. link checks the link before the last confirmed one (a, b, a) itself before calling the 8-link search: unstable (20 alternating reads per run) went from 0.87–0.95× to 1.07–1.13× in the whole suite. Vue's equivalent check (the dep's last subscriber link) does not apply: Roots keeps no per-run pointer on the dep, and in unstable the dep's last subscriber is another computed.

Round two (0.1.7), internal only (no API change except the new createSelector; the 37 behaviour tests pass untouched, 3 were added for createSelector):

• A computed is its own dependency node (as in alien-signals, where a computed is both a dependency and a subscriber): no separate dep object per computed, one indirection less on every read and every propagation step, one allocation less per computed.
• Fields at the same positions. Every dependency (RefImpl, a reactive property's dep, Computed, a selector key) has version, subs, subsTail, flags as its first four fields, and every subscriber has flags, deps, depsTail as its 4th to 6th (a computed is both). The hot paths read these fields from objects of several classes; V8 compiles such a load to one instruction after the class check when the position is the same in every class.
• Machinery only where it is needed. A write no longer opens a batch and a try/finally: only the schedulers of a write (sync watchers, render effects) run user code there, so only they are batched. The flush checks an effect's dirty flag inline before validating it. Validation scans a node's own links without a stack and starts the stack walk only at the first computed that must be validated through its own sources. A connected computed no longer writes its pull-mode validation stamp. Effect scopes allocate their lists on first use. Render effects skip the fn.length check (their functions never take onCleanup) and reuse the base effect's fields for R220.
• Compiler output: module-level variables are var. Every access to a module-level let from a function pays a temporal-dead-zone check (a load and a compare with the hole value); the reactive core reads activeSub, the batch depth and the queues on every operation. Top-level defvar/defparameter now compile to var (inside a function they stay let): 3–5% over the whole suite.

Round one (0.1.4), the rewrite:

• Doubly-linked dependency links (as in Vue 3.5 and alien-signals). A Link sits in the subscriber's dependency list (read order) and in the dep's subscriber list. A re-run walks the list in read order and reuses links, so a run that reads the same sources in the same order allocates nothing and touches no subscriber list; repeated reads in a row, and reads repeated within the last 8 links (a, b, a), keep one link. Before, every run rebuilt two arrays and diffed them through a Set when they changed.
• Push without recursion, pull without recursion. A write marks direct subscribers DIRTY (exact: they read the changed source) and walks downstream with an explicit stack, marking connected computeds PENDING once and queueing effects. Validation walks pending computeds depth-first with an explicit stack, recomputing what turned out stale, so a 20,000-deep chain needs no deep recursion (there is a test).
• Versions decide, flags shortcut. Links keep the dep's version at the first read in a run; a node is stale when a version differs (an effect that read, wrote, then read a source again is still a runaway, R102, as before). DIRTY skips the walk for direct subscribers; a connected, non-pending computed is returned without any check; an unconnected one checks the global version first.
• Lazy subscription. A computed without subscribers is in no subscriber list (nothing keeps it alive) and validates by version; it joins its sources' lists when it gets its first subscriber and leaves them with the last one (iteratively, upstream included).
• Allocation-free hot paths. The effect queue, the scheduler queue and the stacks are arrays with explicit lengths: emptying an array with length = 0 drops its backing store, so the next push allocated a new one on every write; that alone made a write plus effect run 2× slower. Undo closures for transactions are made in helper functions: a closure capturing a writer's locals made V8 allocate a context on every write even when no transaction ran. The effect constructor no longer contains a closure (same reason), and active/queued live in the flags.
• Flat classes. Dep and ReactiveNode are interfaces; RefImpl (a ref is its own dep), KeyDep, ReactiveEffect and Computed declare the shared fields first themselves. V8 builds objects of a class without a base class markedly faster (measured ~30%).
• Compiler output. Numeric defconstants are inlined at their references (each reference was a module-variable load plus a TDZ check in every loop iteration); a leading this parameter types this in TypeScript and is dropped from JavaScript (for the shared array instrumentations); for-in iterates keys without an array.

alien-signals #

The design suggested for round two was a port of alien-signals 2.x/3.x (MIT, Johnson Chu), the algorithm Vue 3.6 adopted: no per-link version bookkeeping, signals that keep a pending value, Pending/Dirty flags pushed downstream and resolved by a checkDirty walk, effects in a flat queue, link reuse with a tail pointer. Roots has had most of that structure since 0.1.4 — one flag word per node with Pending/Dirty, an iterative propagate that marks direct subscribers dirty and everything below them pending, an explicit-stack validation walk that only descends into pending computeds, a flat effect queue, in-order link reuse from a tail pointer — and this round took the computed-as-its-own-node idea from it. It keeps per-link versions: they let a computed without subscribers stay out of every subscriber list (nothing keeps it alive, no leak) and still validate cheaply when read, where alien-signals keeps unobserved computeds linked into their sources.

The decision was measured, not assumed (the earlier machine, the same cases, write → computed → effect, ns per write, medians of 7 processes): a minimal push-pull core with none of Roots' features (no versions, no errors, no scopes, no cleanups, no R102, no schedulers, no transactions) does it in 27 ns; Roots in 64 ns; Vue 3.5 in 90 ns; alien-signals 3.2.1 behind a .value adapter (two extra calls per operation) in 57 ns. Ablating Roots' features one at a time (versions, R102 accounting, onCleanup bookkeeping, error routing, the scheduler queue, the transaction check, the shallow flag…) costs 1–4 ns each, none dominant: the gap to the floor is the feature set, not the algorithm, so swapping the algorithm would not have bought 2×.

Since round nine alien-signals 3.2.1 and its port in Vue 3.6 are measured directly, in their own notation and without an adapter object (the field table above): 0.3.0 was behind Vue 3.6 rc on the mean (0.95) and ahead of alien-signals by 1.14; the tree is ahead by 1.13 and 1.36. The cases where their design still wins are the ones the paragraph above predicts: validation walks without versions, and computeds that stay linked.

What is still slower, and why #

The goal against Vue 3.5 was 2× on the geometric mean and no case slower. The mean is 1.70–1.72×: still missed. No case is resolved slower than Vue 3.5 any more. Against the field Roots leads the mean and 19 of 30 rows, and is behind in these:

• Writes to refs nobody reads: dynamic: simple component (pull), 0.75 against Vue 3.6 rc (Preact 1.01, alien 1.48, Vue 3.5 1.26). The case is 200,000 writes without a subscriber, so it measures the ref setter alone: a call of Object.is, the test for a shallow ref, two counters and the call of trigger. A prototype with === and no shallow test reached 1.20–1.27 on this case, which would still leave Vue 3.6 ahead, and is not shippable (NaN, and deep refs). The two setter variants of round nine did not leave their control. This is also the one case where 0.3.1 is slower than 0.3.0, by about 3% (above); the cause has not been looked for.
• avoidable propagation, 0.78 against Vue 3.6 rc (alien 0.94, Preact 0.98, both inside the band). Not attributed: the two libraries run the same getters the same number of times (exact), so the difference is the cost per step of the validation walk. mux 0.91 (alien 0.94), computed chain 0.93, deep propagation 0.95 (alien 0.96) are the same walk. Three variants of it were measured in round nine and dropped; removing a single feature from the walk (the R102 accounting, the try/finally, the cleanup test, the transaction check) is worth at most 4% each.
• Reading computeds nobody observes: dynamic: simple component, 2 leaves (pull), 0.83 against Vue 3.6 rc (alien 1.03). This one is a choice. Vue 3.6 and alien-signals keep an unobserved computed subscribed to its sources, so a read finds its flags current; Roots keeps it out of every subscriber list and validates it by version on each read. The other side of it: in Vue 3.6 a live source keeps every computed that ever read it, 256–280 B each, until the source dies; in Roots a dropped computed costs nothing. A prototype of the linked design gained 1.26 on this case and lost 5–8% on two others. Not closing this gap is the decision.
• Wide graphs: dynamic: wide dense (effects), 0.69 against reactively (Vue 3.6 1.19, alien 1.45). reactively keeps a node's sources in an array and compares positions; Roots walks linked nodes. Closing it means array dependency lists, a rewrite of the core's data structure. reactively cannot dispose anything, and is 1.43 behind on the mean.
• Creating effects: level, not ahead. create 1to1000 is 0.97 [0.83–1.34] against Vue 3.5 and 1.00 against Preact, create 1to1 1.02 and 1.04; Vue 3.6 and alien are behind on both (1.12–1.28). effect() still reads fn.length once per effect, to give a function that declares onCleanup a registrar it may keep and call after the run, as R106's message promises. Without the read a prototype measured 1.46–1.63 over 0.3.0 on create 1to1000 where the shipped core measures 1.25–1.39. Removing it means changing what onCleanup promises (valid during the run only, as Vue's onEffectCleanup); the decision is to keep R106 as documented, and effect(fn, { cleanup: "run" }) is the opt-out for callers that can make the promise themselves.
• Why not 2× over Vue 3.5: Vue 3.5 already uses linked dependency nodes and version counters, so the differences are constant factors. Roots is at 2× or more where Vue does extra passes or recurses (update 1000to1 2.9×, computed chain 2.4–2.6×, update 4to1 2.2–2.4×, triangle, diamond, deep propagation 2.0–2.2×) and at 1.2–1.6× where one tracked read or one write plus effect run is all there is (mux, dynamic: simple component (pull), create 100000 signals, 100k writes, unstable).
• What is not claimed: "fastest in every case" (the table above), and anything about libraries that were not measured. Vue 3.6 is a release candidate; its final release may measure differently.

Rendering #

Method #

runtime/bench/run-render.mjs builds three versions of the js-framework-benchmark keyed app and drives them in one headless Chromium:

• Roots: runtime/bench/render/app (one src/App.vue), built with the real toolchain, roots build --target web: one bundle, tree-shaken, minified, DEV false, strict CSP. The row class is :class="{ danger: isSelected(row.id) }" with isSelected = createSelector(selected).
• Vue 3.5.44: the same App.vue compiled with @vue/compiler-sfc (<script setup>, inline template, production mode) against vue.runtime.esm-browser.prod.js. The only edits: the import specifier, and the selection test, which becomes row.id === selected plus the v-memo that Vue's own benchmark entry uses (v-memo="[row.label.value, row.id === selected]"), i.e. Vue at its best (Vue has no selector primitive; v-memo is its tool for the same job). Data model as in that entry: a shallowRef array of rows whose labels are shallowRefs.
• vanilla: hand-written DOM code (template cloneNode, one delegated listener).
• vanilla with a template (vanillatpl): the same code with one line more, which moves its row prototype into the content of a <template>, an inert document. In Chromium a clone from there is cheaper, so on the operations that create rows this is the floor, not vanilla; on the others the two are the same code.
• The field (--frameworks, since round nine): the js-framework-benchmark keyed entries of Solid 1.9.18, Svelte 5.57.3, Preact 11.1.1, ivi 5.1.0, lit-html 3.3.3, Inferno 10.0.0 and Vue Vapor 3.6.0-rc.14 (a release candidate), ported from upstream with this harness's seeded label generator (so the DOMs can be compared), each compiled by its own compiler and bundled and minified with esbuild (render/build-field.mjs). lit-html as shipped leaves one comment node in the table per removed row and gets slower with every operation until a page that lives as long as this harness's pages no longer finishes; the tables use litfix, the same app with that one line of lit-html patched, and say so. A session has at most five pages, with Roots, its A/A copy and vanilla in each.
• A/A (--aa): a copy of the Roots build as one more page; base (--baseline <checkout>): the same app built by another checkout of the toolchain.

Every measurement resets the app (Clear), prepares the state (untimed, e.g. Create 1,000 rows), then clicks the button or row link like js-framework-benchmark, waits for the framework's update (nextTick), and forces style and layout (offsetHeight): the time is performance.now() around click → update → layout, in the page. The pages are served with COOP/COEP, so the timer has 5 µs resolution instead of 100 µs. A second table reports the script part alone (click → update applied, before style and layout). All pages are open at once and measured in turn, the order rotated by one every second round and reversed on every other round, after warm-up rounds; medians, with half the IQR as spread. After every run the DOMs are compared (row count, ids and labels of rows 1, 2, 11, 998, 999, selected rows); none differed. Memory is the JS heap after two forced GCs (CDP), median of 5 page loads; size is the JavaScript the page loads, gzipped file by file, and for reference esbuild --bundle --minify over each app's unminified modules (for Roots the modules of roots build --no-bundle --no-minify, so that row compares Roots' tree shaker and minifier with esbuild on the same input).

Results #

Measured on 11 November 2026 on the tree of 0.3.3, Chromium 143 unless a table says otherwise, 15 runs after 3 warm-up rounds, load average 5–11. Every session has Roots, its A/A copy and the hand-written app; a framework is bold in a row when its ratio lies outside the control of that row in every session it ran in (the control's own deviation, at least ±5%).

The field, script time (click → update applied). Six sessions of five pages: Solid + ivi, Svelte + Vapor, Inferno + Preact, lit-html + Vue 3.5, the template version of the hand-written app + Vapor, Solid + the template version. Each cell is that framework's median over Roots' median in the same session: above 1, Roots is faster. Two numbers are two sessions. "Roots ms" and "A/A" are ranges over the six sessions, vanilla too. Vue Vapor is 3.6.0-rc.14, a release candidate; lit-html is the patched build (see "Method").

On the geometric mean of the nine operations Roots has the lowest script time of the frameworks measured. The nearest is Vue Vapor 3.6 rc at 1.08 and 1.12, then Inferno 1.38, Solid 1.38–1.40, ivi 1.51, Svelte 1.65, lit-html 1.76, Vue 3.5 3.26 (3.35 in the session against 0.3.0 below), Preact 6.94. Operation by operation:

• Roots is not the fastest on select: Vapor is, 0.90 and 0.89, outside the control in both sessions, and 0.94 in a third session of 41 runs (control 1.00). At 0.08–0.10 ms that is one or two 5 µs timer steps, and it has the same sign every time.
• Level with Vapor, inside the control or with one session on each side of it: create 1,000 (0.99, 1.06), replace (1.00, 1.04), partial update (1.06, 0.96), create 10,000 (1.00, 1.07), clear (0.97, 1.02). Ahead of Vapor on append (1.08, 1.07), swap (1.45, 1.48) and remove (1.43, 1.77).
• Level with Solid on creating rows: create 1,000 1.02 and 1.04, create 10,000 1.06 and 1.03, each inside the control in at least one session; ahead on append (1.10, 1.11) and on every other operation but clear. At 0.3.0 Solid was ahead on all three (0.80, 0.75, 0.85).
• Ahead of Inferno, ivi, Svelte, lit-html, Vue 3.5 and Preact on every operation that is resolved; clear is level with Inferno and Svelte.
• Hand-written code is faster on everything but clear, and its template version is the floor on creation: Roots needs 1.54–1.59× its script time to create 1,000 rows, 1.27–1.32× for 10,000, 1.31× to append, 1.14–1.19× to replace; and 1.5–1.9× on partial update, swap and remove, 2.4× on select, where both take 0.04–0.2 ms. The hand-written app with a template is itself 0.71–0.88× of the one without on create, create 10,000 and append (2.9 against 4.4–4.5 ms for Roots on create 1,000).

The field, totals (script + style + layout), same sessions and rules:

With style and layout in the window the field is within a few percent: on seven of the nine operations layout is 80–97% of Roots' total. In totals Roots is not first: Vue Vapor reads 0.96 in both sessions against controls with a geometric mean of 1.00, outside the control on replace (0.95, 0.93) and select (0.93, 0.93); Solid is level (0.98, 1.01), ahead on replace (0.94, 0.95). Roots is ahead of Vue 3.5 by 1.29× (1.34× in the session below), of Preact by 1.83×, of lit-html, Svelte and ivi by 1.11–1.18×, and level with Inferno (1.04). Where the script time is lower and the total is not, the difference is in style and layout, which no framework code runs in; why Vapor's and Solid's totals are 5–7% lower on replace has not been looked into.

Firefox 144, two sessions. The first (Roots, its A/A copy, Vue 3.5, Solid, vanilla; the timer steps by 20 µs there, so select, swap, remove and partial update are a few steps):

A second session with Solid and vanilla only read, for Solid / Roots in script: create 1.15, replace 0.84, partial update 1.22, select 0.89, swap 1.53, remove 1.13, create 10,000 1.08, append 1.63, clear 1.02; geometric mean 1.14. Together: in Firefox Roots is ahead of Solid on create, append, swap, remove and partial update, and behind on replace (0.69 and 0.84: 28–31 ms against 21–23 ms); select reads 0.80 and 0.89, one or two 20 µs steps; against Vue 3.5 the script mean is 3.28×. In totals Solid is ahead (0.93 and 0.94), and Roots' totals for swap and remove are 12–15% above everyone's in both sessions, the hand-written app's and Vue's included (26–27 ms against 22–24 ms; A/A 0.97–0.99). The gate's Firefox session measured 0.3.2 with the same totals as the tree (1.02 and 1.05), so this is not new in round ten; it had not been measured before, because nothing before round nine ran in Firefox. Neither it nor the replace time is explained. Template prototypes are not homed in Firefox, so there Roots is compared with the hand-written app as written: 1.5–1.7× its script time on create and append.

Against Roots 0.3.0 (the frozen tree as base; two sessions, the first with Vue and vanilla as well):

Script geometric mean 1.21 and 1.20 (controls 1.01 and 0.99): creating rows is 1.29–1.40× faster, swap 1.45–1.61×, remove 1.19–1.35×, replace 1.14–1.16×. Partial update (1.07 next to a control of 1.05, then 1.02), select (1.00, then 0.95 at one timer step) and clear are not resolved; the gate's sessions of 101 and 151 runs against 0.3.2 had select's medians equal. Totals 1.03 and 1.01 (controls 1.02 and 1.00): no difference shown, as before. Against 0.3.2 the gate's sessions measured the same gains (script geometric mean 1.18–1.20 in four sessions): the rendering work is all in round ten.

Against Vue 3.5.44 (the first of the two sessions above: Roots, its A/A copy, 0.3.0, Vue, vanilla; load average 5–6). Totals, medians ± half the IQR:

Geometric mean speedup over Vue: 1.34×; faster than Vue on 9 of 9 operations (A/A 0.98–1.04 per operation). Script only (click → update applied, before style and layout):

Geometric mean script speedup over Vue: 3.35× (A/A 0.97–1.12 per operation); the field session with Vue read 3.26× in script and 1.29× in totals (0.3.0: 2.89× and 1.29×). Faster on all nine operations in both: remove 16×, select 4.7–5.1×, swap 4.6–4.9×, partial update 3.6–4.0×, append 2.5–2.6×, create 10,000 2.5×, create 1,000 2.2–2.3×, replace 1.8×, clear 1.2×. In totals Roots is within 0.90–1.08 of the hand-written app.

What is exact:

A Roots row now keeps one list record (84 B), one render effect (60 B, the label), one selector binding (48 B), one ref (the label), two dependency links and one closure; at 0.3.0 it kept two render effects, four links, two refs, four closures and a selector key. The loaded app is 0.03 MB larger than at 0.3.0 and larger than every app of the field but Vue 3.5's.

Roots asks the DOM for the least of all frameworks measured, as before; the other operations are unchanged (partial update 100 writes everywhere, select 1, swap 2, remove 1, clear 2 in Roots). Function calls of the runtime for the same 1,000 rows: 74,061 (0.3.2: 130,060; hand-written: about 4,000).

The field's apps are bundled and minified by esbuild; KB are 1,024 bytes, gzip is per file. esbuild bundling Roots' own unbundled modules gives 57.4 KB / 20.4 KB, so Roots' bundler and minifier together now end slightly below it (at 0.3.0: equal in gzip, 10% above it raw); the shaker keeps less, the minifier alone is still 1.3–1.7% behind esbuild's (below). The unbundled layout is 5 files, 214.0 KB, 61.2 KB gzip (0.3.0: 188.1 / 53.4 KB): the runtime has grown by 14% since 0.3.0 (security hardening in 0.3.2, the new helpers in 0.3.3), and the minifier's new syntax rules hide that in the bundle.

Raw bytes fall by 5–11%; gzip by 0.7–5.6% except for todo, which is 59 B larger. Against esbuild --minify on the same shaken text the bundle is 1.3–1.7% larger raw. A hello world of the field, measured in round nine and not again: Solid 5.0 KB gzip, Preact 5.7, Svelte 17.0, Vue 3.5 22.5; Roots 15.2 KB.

Results of 0.3.0 (round eight), for the record #

Measured on 10 November 2026 on the same machine under more load, so the milliseconds are not comparable with the tables above. Session 1, 15 runs after 3 warm-up rounds, five pages (Roots, its A/A copy, the tree after round five as base, Vue, vanilla), load average 4.8 at the start and 11 at the end:

Geometric mean speedup over Vue: 1.29×; faster than Vue on 9 of 9 operations.

Script only (click → update applied, before style and layout), medians:

Geometric mean script speedup over Vue: 2.89×.

Session 2 ran right after it, with Roots 0.2.1 as the base and under more load (11 at the start, 27 at the end; spreads of ±5–26% on the totals, ±5–16% for Roots). The speedups over Vue of both sessions, each next to the A/A control of its cell (the A/A copy's median over Roots' median: what identical code measured there):

Geometric means: script 2.89× and 2.83×, totals 1.29× and 1.28× (session 2: faster on 8 of 9, create 1k 0.93×). The controls range over 0.84–1.88 (script) and 0.85–1.01 (totals) in session 1, 0.95–1.67 and 0.94–1.07 in session 2: the totals and the script times of the large operations are stable to about ±15%; remove row and swap rows take 0.2–0.5 ms of script and read up to 1.9× apart on two copies of the same page, so their speedups (13.9–15.4× and 3.2–3.3×) are known to that factor only: against the slower copy remove is 8× and swap 2.7×.

Against Roots 0.2.1 (session 2; 0.2.1 ships 5 unminified modules with its development checks on, 0.3.0 the bundle):

Geometric mean 0.2.1/0.3.0: script 1.14× (per operation 0.91–1.58), with a control of 0.95–1.67 per operation and a geometric mean of 1.12; totals 0.99× (0.93–1.05), control 0.94–1.07. On the geometric means, no difference shown. Two operations read below the control's range, that is, 0.2.1 measured faster: partial update's script 0.91× (0.04 ms), and clear, 0.93× in script and in totals (11.1 → 12.0 ms and 11.3 → 12.1 ms, 0.8–0.9 ms slower), just under the lower ends of 0.95 and 0.94 and next to an A/A of 0.95 in its own cell. Session 1 has clear with the same sign against the tree after round five (0.96× script, 0.97× total, inside that session's control). Clear was therefore listed as a possible regression of about 5%, not shown and not excluded by these sessions (in the two sessions of 11 November against 0.3.0, clear reads 0.99 and 1.01). Read cell by cell in the other direction, create 1k (1.26× next to a control of 1.04), create 10k (1.19×, 1.05), append (1.39×, 1.15) and swap (1.58×, 1.16) lean faster; it takes a quiet machine to say either. The same comparison against the tree after round five (session 1) gives script 0.98× (0.88–1.04, control 0.84–1.88) and totals 0.99× (0.91–1.10, control 0.85–1.01): inside the control except append's total, 1.10× (118 against 107 ms; A/A of that cell 0.95), which is above the control's upper end as run-render.mjs prints it and inside it when the range is mirrored (0.85–1.18). Round seven compiles this app to the same code, so nothing was expected to move here.

What was exact at 0.3.0 (heap sizes from session 2; session 1 read 2.28 MB for Roots, 2.27 MB for the tree after round five and 3.48 MB for Vue):

A Roots row of 0.3.0 kept 4 dependency links, 4 closures, 2 render effects, 2 refs (the item and its label), one list record and one selector key; the 0.2.1 row also kept an owner with its effect scope and a render effect for the row's id, which is now written once.

The other operations: partial update 100 writes in all three; select 1; swap 2; remove 1; clear 2 in Roots, 1,000 removeChild in Vue, 1 in vanilla.

At 0.3.0 Roots' own bundler and minifier ended at the same gzip size as esbuild on the same modules (19.3 KB) and 10% above it raw (59.3 against 53.7 KB): the minifier of that release renamed bindings and removed whitespace but did not rewrite expressions or mangle properties (docs/bundling.md §9, §10). The unbundled modules grew from 41.4 to 53.4 KB gzip since 0.2.1 (the runtime gained code in rounds four to seven), and round seven alone grew the bundle from 18.7 to 19.3 KB gzip (57.7 → 59.3 KB raw; unbundled 48.5 → 53.4 KB; session 1's size table for the tree after round five). The todo example ships 23.1 KB gzip as one bundle (71.4 KB raw) against 62.5 KB in 16 files for that release's own --no-bundle output; 0.2.1's build of it was not measured.

Template patterns of real components #

The benchmark's row is lowercase HTML with one bound class, which no Roots component looks like: real components are host primitives (Box, Text, Button), text with several interpolations, child components, slots, v-model, v-if, bound attributes. run-patterns.mjs measures seven list components, one per pattern, 1,000 rows each, four operations (fill, replace every 10th item, replace every item, clear): script time (change → nextTick). Vue is the same components compiled by @vue/compiler-sfc with the primitives written as the HTML the DOM backend creates for them; "0.3.0" is the same app built by the frozen tree of 0.3.0. Ratios are other/Roots on the medians, above 1 when Roots is faster. Two sessions on 11 November 2026, of 11 and of 21 runs after 3 warm-up rounds (load average 7–13); two numbers in a cell are the two sessions, bold when outside the A/A band in both. The bands are 0.80–1.26 and 0.86–1.16 (the widest control cell of each session, mirrored). Milliseconds are the first session's.

• Against Vue 3.5: geometric mean 1.81× in both sessions, 0.75–4.63 per cell; outside the band on 22 and 23 of 28 cells. Replacing some rows is 2.0–4.6× faster in every pattern; creation is ahead for components (1.75–1.88×) and slots (1.46–1.59×) and inside the band for primitives (1.13×), v-model (0.98, 1.03) and attributes (0.98, 0.99).
• Behind Vue in three patterns, each outside the band in one of the two sessions: text/fill 0.83 and 0.81, if/updateAll 0.75 and 0.89, attr/updateAll 0.85 and 0.81; if/fill reads 0.91 and 0.87, inside both bands. These are the same three as at 0.3.0 (0.82, 0.85, 0.92): nothing in rounds nine and ten was aimed at them.
• Against 0.3.0: geometric mean 1.09 and 1.07, three cells outside the band in each session and no cell resolved slower. What repeats is the partial update: text/update10 1.81 and 1.94, slot/update10 1.49 and 1.23, prim/update10 1.46 and 1.08, and text/updateAll 1.21 and 1.24. The gate against 0.3.2 resolved no cell (geometric mean 1.03 at 21 runs), so these gains belong to 0.3.1 and 0.3.2; which change it was has not been measured. Fills read −2 to +14% in the first session and −9 to +8% in the second, inside the bands: round ten's creation gains are those of the benchmark's row (see "What made the difference").
• Totals with style and layout (the last two columns; the tool computes no band for totals): Roots' median is lower on 21 of 28 cells, geometric mean 1.22× in both sessions. Vue's is lower on prim/fill by 20% in both sessions (21.7 against 27.3 ms, then 20.5 against 25.8; the A/A copy and 0.3.0 read 26.4 and 27.8, then 24.6 and 22.1), which is more than at 0.3.0 (0.93×) and is not explained: the script times of that cell are 4.9 against 5.5 ms the other way. Vue is also lower by 1–6% on model/fill, text/fill, if/fill, attr/fill and if/updateAll (0.89, 0.96), none of them resolved. Every variant produced the same DOM fingerprint for every pattern and operation.
• Primitives against plain tags (a third session with Roots' rows written as the lowercase HTML the DOM backend creates, band 0.89–1.13): geometric mean 1.00, 25 of 28 cells inside the band. Outside it: comp/fill 0.88 and slot/fill 0.87 (the lowercase rows are created 12–13% faster) and if/fill 1.22 the other way, as at 0.3.0. Against Vue that session read 1.82× (text/fill 0.86, attr/updateAll 0.81 and if/fill 0.88 outside the band, if/updateAll 0.93 inside).
• History, 0.3.0 against the tree before round seven (10 November 2026, band 0.76–1.32): geometric mean 1.25×; creation of primitives 1.59×, components 1.57×, attributes 1.55×, v-if 1.40×, slots 1.39×, text 2.33×; text update-all 1.56×, text clear 2.35×. That was the round that moved primitives into static templates and made a text run one binding.

Kit widgets and component instances #

run-widgets.mjs mounts 100 instances of one kind and reports the script time and, with --heap, the live JS objects and bytes per instance from two heap snapshots. No Vue column: the kit has no Vue build. "0.3.0" is the frozen tree of 0.3.0; 15 runs after 3 warm-up rounds on 11 November 2026; A/A band of the session 0.92–1.09; load average 7–8.

Against 0.3.0 the median over the kinds is 1.13× (1.03–1.31). Clearly outside the band: box and div 1.31×, plain 1.24×, input 1.19×, field 1.15×, todo 1.13×; at its edge: badge 1.11×, button 1.10×, switch 1.09×; inside it: select, card. No kind is slower. Against 0.3.2 the gate's session resolved no kind in either direction (median 1.008, band 0.90–1.12), so this gain is not round ten's either; it arrived with 0.3.1 and 0.3.2.

Objects per instance are exact and are 0.6–1.1 fewer than at 0.3.0 for every kind. Bytes are not exact in this tool: two copies of the same build differ by up to 100 B per instance (the "its copy" column; badge 1,972 against 1,876). A review session with an exact control found badge and card 17–18 B per instance larger than in 0.3.2 (under 1%) with one object fewer, and box, div, plain and button 12–83 B smaller: a list's record is 84 B where it was 72 B, and a list keeps two more arrays.

History, 0.3.0 against the tree before round seven (10 November 2026, band 0.93–1.08): every kind 1.27–1.89× faster to mount, median 1.44×, with 21–52% fewer live objects per component instance (a one-prop component 84 → 41 objects, 2.8 → 1.5 KB; a kit Button 154 → 99; Field with its Input 445 → 303).

Startup #

run-startup.mjs loads each build in a warm renderer under a fresh URL (nothing cached, Cache-Control: no-store) and reports, from the request of the entry script, the first render: the moment the mount point gets its first child. "fetch" ends with the last module's response; "script after fetch" is the rest (compile finalization, evaluation, mount). 25 loads on localhost, 20 over an emulated network (25 ms latency, 10 Mbit/s, gzip); medians ± half the IQR; 11 November 2026, load average 6–9. Ratios are to Roots' bundle, above 1 when Roots renders first; bold outside the session's A/A band.

The field, bench app (each framework's js-framework-benchmark entry, built by its own compiler and esbuild; they mount into an empty element of the page, and their first render is that element's first child element):

Roots renders first among the three frameworks of its own size class (Vue 3.5 1.85–1.96×, Vapor 1.09–1.15×; Svelte is level: 1.08 and 0.97, inside the bands) and later than the five small ones: Solid, Preact, lit-html, Inferno and ivi render in 4.8–5.4 ms where Roots needs 8.9 ms, and in 38–45 ms over the network where Roots needs 57 ms. The difference is the bundle: they ship 4.4–10.2 KB gzip, Roots 19.6 KB (see "What is still slower"). Vapor's ratio over the network (1.09) sits on the upper edge of that session's band.

Output layouts of Roots itself: the bundle (roots build), --no-bundle as shipped (one modulepreload link per module and the compile hint //# allFunctionsCalledOnLoad in each), the same files with links and hints removed, and the bundle of 0.3.0:

The bundle renders first in every condition: one request instead of 5 or 16, and a third of the bytes. Preload links turn the unbundled graph's fetch rounds into one; the compile hint moves compilation off the main thread and under the fetch (todo, localhost: 8.8 → 2.8 ms of script after the last response). The bundle has no compile hint, and round ten measured that it should not get one: see "What made the difference" (it helps the todo example and slows the bench app).

Against earlier bundles the first render has not moved. In the tables above the bundle of 0.3.0 reads 0.97 and 1.05 for the bench app and 0.96 and 0.97 for the todo example; the 0.96 (localhost, outside a band of 0.99–1.01) did not repeat in a session of 40 loads (11.01 against 11.18 ms: 0.99, band 0.98–1.02). Against 0.3.2 at 40 loads: todo 0.99 (band 0.98–1.02), bench app 1.01 (band 0.99–1.01). No difference shown in either direction.

The times of 0.3.0's own startup tables (bundle 13.3 ms on localhost, Vue 24.4 ms, todo 23.1 ms) were measured on 10 November under more load and are not comparable in milliseconds; the ratio to Vue was 1.84× then and is 1.85× now. Cold renderers and repeat visits (--proc cold|repeat) were not measured.

What made the difference #

Round ten (0.3.3). Every item was kept or dropped by a gate on the combined tree against the frozen 0.3.2 checkout, in sessions with their own A/A control (10 November 2026, Chromium 143, Firefox 144, WebKit 26). Ratios are 0.3.2 / tree on script time, with the control of the same row in brackets.

• Template prototypes live in an inert document. The DOM backend moves a template's prototype into the content of one shared <template> (the new optional backend method home), which is where Solid, Svelte, ivi and Vue Vapor clone their rows from. In Chromium a clone from there is cheaper, also for hand-written code ("vanilla with a template" in the tables). The tree against the same tree with this switched off: create 1,000 1.21 [1.04], create 10,000 1.17 [1.02], append 1.11 [1.00], replace 1.07 [0.99]. It is off in Firefox, where smoke runs showed no gain, and for templates with a custom element, a <video> or an <audio> (see "Semantics notes"). In WebKit it is on; one session measured a small gain on create 10,000 and a second could not resolve it (control 0.78–1.09).
• The list update is a scan over two key arrays. ListBlock.update keeps the keys of the previous render, finds the common prefix and suffix and a two-element exchange by comparing keys, and touches only the records that differ; it is split into the scan and one function per case. Keys are still computed eagerly, so key semantics are as before. Swap 1.48–1.65 in four sessions [0.97–1.00], remove 1.17–1.41; function calls for a swap 2,068 → 1,073 (exact).
• Lean helpers for nodes the compiler knows. For a plain element of a static template on a DOM target the compiler emits setElText, bindElText, bindClassEl and onEl, which skip the tests the general helpers make for blocks, text nodes and checkboxes, and tells forBlock when every item is one element. Against the new runtime with the general compiler output: append 1.16 and 1.14 [1.02, 1.03], create 10,000 1.07 and 1.12 [0.97, 1.03], create 1,000 1.10 and 1.04 [0.97, 0.95]: resolved on append and create 10,000 in both sessions, on create 1,000 in one.
• Row handlers are shared. A handler in a v-for row is one descriptor per handler site and render of the list, registered with the row as its data (onRow), where each row had two closures. No time is resolved for it (create 0.98 and 0.94 [0.97, 0.95]); it is kept for the count: 2 objects and 56 B fewer per row.
• A selector class needs no render effect. :class asking a createSelector result registers a 48-byte binding with the selector, which queues it into the render flush when its key gains or loses the selection. Kept for memory only: 4 objects and 148 B fewer per row; select is level with 0.3.2 in four sessions of 101 and 151 runs (medians equal, trimmed means 0–3 µs apart, as far as two copies of one build differ).
• The record is the item's dependency: one object and 22 B fewer per row, no time.
• Together, per 1,000 rows of the benchmark app (exact): function calls for create 130,060 → 74,061; live JS objects per row 22.9 → 16.0; bytes per row 786 → 560.
• These are the gains of the benchmark's row. Measured on other row shapes (11 runs, controls 0.93–1.08): creation 1.12 with bound attributes, 1.14 with a static and a dynamic class, 1.21 non-keyed, 1.18 with two root elements per item, 1.10 with a list inside each row, 1.07 with a component inside each row. The swap gain carries wherever a key exists (1.58–2.18). Nothing measured was slower than 0.3.2 in Chromium.
• The minifier writes shorter syntax: no ; before }, merged declarations, unbraced single statements, !0 / !1, void 0, and no description on symbols that are only keys. The bundle is within 1.3–1.7% of esbuild --minify on the same text (0.3.0: 10% above it raw). on is split from onWith (the modifier half leaves apps without event modifiers) and clone no longer tests the backend in DOM bundles.
• Dropped: a compile hint on bundles. //# allFunctionsCalledOnLoad as the bundle's first line makes the todo example render 8–9% earlier on localhost and the bench app 7–9% later (controls 0.97–1.04), with nothing on the gallery and nothing over the emulated network. The rule was "better on two apps, worse on none".
• Not needed: lazy keys (not recomputing the key of an identical item object), which would have changed what happens to an item whose key field is mutated in place.

Rounds four to seven. The session of each round measured its steps against the tree before it, under load, with the method of the time; what is quoted here is what round eight's tables (0.3.0) show for the sum, and the exact counts.

Round seven (what real components are made of; the benchmark row compiles to the same code as before):

• Host primitives in static templates. Box, Text, Button, Image and Spacer subtrees are cloned like lowercase elements (Input, Checkbox and Link stay $.element calls); the root of a v-for item has its static class and style baked into the prototype; the backend's new optional adopt(node, tag) gives a copied Box or Spacer the state createElement would have given it. Before, no compiled Roots component took the clone path at all: all of them are written with primitives. Patterns: prim/fill 1.59×, comp/fill 1.57×, attr/fill 1.55× against the tree after round five.
• One binding per text run. Adjacent text and interpolations compile to one getter that concatenates the parts, written as its element's text content where the run is all the element holds: one text node and one render effect where each part had its own. text/fill 2.33×, text/updateAll 1.56×, text/clear 2.35×; v-if rows, which hold text, 1.34–1.50×.
• Development checks are off in production builds. roots build defines DEV false (the bundle folds the branches away; --no-bundle replaces __ROOTS_DEV__ at link time), and prop validation moved under it: until then every component validated its props at mount in every build, reading each declared prop once.
• Lighter component instances. Hook lists, $refs and the default cache are made on first use; components that were passed no attrs share one empty attrs view; the props and attrs views share one Proxy handler and the _ctx proxies another, instead of closing over their instance. Per-node state lives in a symbol-keyed property instead of a WeakMap. Objects per one-prop component: 84 → 41.
• A bound attribute's first value is not written when it only says "absent" (null, undefined, a removing false): a kit Input no longer calls removeAttribute for every attribute it never had.
• Bindings that read nothing reactive are released after their first run (:label="'Save'", a constant behind a getter): they cost no memory and nothing to dispose.
• Kit: a part without pass-through evaluates its class to the skin's string directly (no array, no normalizeClass, no per-key closures).
• Together these are the widget table: 1.27–1.89× on mount, 21–52% fewer objects per component instance.
• Unbundled output: modulepreload links with SRI for the static import graph, and the compile hint, on DOM targets and in roots dev (from the startup tables: first render 1.21× earlier on localhost and 1.46× on the emulated network for the bench app, 1.35× and 1.41× for todo, each against the same files without them).

Round five (the row's object graph and the update path; measured then against the tree after round four, now part of the 0.2.1 comparison above):

• A list item is a scope, not an owner. A forBlock has one owner for the whole list; each item is a record that is the scope of its effects and holds the owners nested in it. A row costs no owner, no effect scope and no set entry.
• Render effects are slimmer (EffectBase, see Reactivity): the benchmark row keeps 2 of them, 60 bytes each.
• Kept rows are not touched. An update leaves a kept item alone when its value is the same object and it received no index or key ref; the list's block keeps no node list of its own.
• The key's text is written once. An interpolation that shows the key of its keyed v-for ({{ row.id }} under :key="row.id") compiles to $.setText, no render effect: a kept row only ever receives an item with the same key.
• Event handlers run through batchCall(fn, arg), which allocates no closure per event.
• Measured and not adopted: one grouped effect per row (faster creation, slower partial updates), rows without an item ref, a straight-line clone walk, hoisted row handlers, an inline render mode without _ctx, a patch of Event.prototype for currentTarget. Each was inside the noise or cost something Roots leads in. (Round ten shipped two of them in another form: the record is now the item's dependency, so the row has no item ref, and row handlers are shared; both are kept for their exact counts, not for time.)

Round four (per-row work in the runtime and the DOM backend):

• An interpolation alone in its element is the element's text content: no empty text node in the prototype, clone collects the element, the first run writes textContent (the DOM makes the text node itself, as hand-written code does).
• Registering a listener allocates nothing. The backend's optional listen keeps the compiled handler and its component in symbol-keyed properties of the node; one invoker serves every listener. No closure and no remover per row.
• The template walk is one backend call (collect: direct property reads into a preallocated array, an ancestor stack instead of parentNode), and the prototype is cached in the template for the first backend. A created row costs 5 DOM reads (firstChild 3, nextSibling 2: 5001 for 1,000 rows).
• A bound class allocates its node's state only once it has a class to write: :class="{ danger: selected }" on a thousand unselected rows keeps none.
• A swap needs no key map: two items that exchanged places move directly (2 insertBefore, 1 for neighbours).
• DEV exists since this round, with the R215 duplicate-key scan of pure insertions under it; the render queue keeps its storage across flushes. A DocumentFragment for insertions was measured and not adopted (slower in script).

Round six changed no runtime code. It measured the todo example, the gallery and the kit instead of the benchmark and found that rounds one to five had optimised a path only the benchmark app reached (no compiled component contained a static template), that every built app ran its development checks, and that the unbundled layout was the one place Roots lost to Vue (first render over a network). Round seven is its plan; the tools it wrote are run-startup.mjs, run-patterns.mjs, run-widgets.mjs and ab-reactivity.mjs.

The earlier rounds, measured on the earlier machine (the numbers in them are that machine's, against Vue 3.5.45 and the unbundled build):

Round two (0.1.7):

• Event delegation (DOM backend). Listeners for the common bubbling events (click, input, keydown, pointer and mouse events, focusin/focusout…) are no longer added to each element: every document gets one listener per event type, and an element keeps its handlers in a property (a symbol per event type). The document's listener walks composedPath() from the target up and calls the handlers like native listeners (registration order, currentTarget set, until stopPropagation()), Solid's approach. Creating 1,000 rows no longer calls addEventListener 2,000 times nor allocates 2,000 removers: create 1k script 8.9 → 7.7 ms in an A/B run. The exact semantics, and what differs from per-element listeners, are in docs/runtime.md §6.
• createSelector (new, opt-in, docs/runtime.md §2): isSelected(key) makes a binding depend on its own key only, so selecting a row re-runs two class bindings instead of 1,000: select script 0.39 → 0.13 ms (Vue with v-memo: 0.42).
• Template walk programs. A static template now precomputes the moves (first child, next sibling, parent, take) that reach its collected nodes in a copy, and never visits nodes after the last one needed in an element (the row's remove icon and last cell).
• The reactivity work above (render effects are reactive effects).

Round one (0.1.4):

• Static templates (template compiler + runtime). A subtree of two or more plain HTML elements becomes a spec hoisted to module level ($.template([...])); the render code clones it ($.clone, one cloneNode(true) on the DOM) and binds only the nodes that need it ($.bindText, events, :class…, holes for blocks and components via $.insert). The prototype is built once per backend with the backend's own createElement/setProp, so every security check still applies (tests: R304 refused, R307 dropped). Only state-free things go into a spec (rules in docs/templates.md §3); backends without cloneNode (the terminal) get the same nodes built by the helpers, and a test checks that the clone path and the helper path give the same tree at every step. Create 1,000 rows: script 23.5 → 8.6 ms.
• Class strings without objects. :class="{ danger: row.id === selected }" on an element compiles to () => ((…) ? "danger" : ""), what normalizeClass makes of the object, so re-running a row's class allocates nothing (select: Roots went from slower than Vue to 1.1× faster in script time).
• One object per binding. A RenderEffect (a subclass of the reactive effect) holds the binding's state (node, getter, last, key, part) and runs a shared update function per binding kind with a shared scheduler. Before: a job object, an effect, a wrapper closure, a scheduler closure and the binding closure per binding.
• Render jobs re-run only when a source changed (an unchanged computed or prop stops there), are queued by append (subscribers are notified in creation order; the old code did a binary search and a splice per job) and allocate nothing per run.
• Class merging without maps. A node with one class source keeps it in two fields; a bound class compares the normalized string before touching the merge, so selecting a row re-runs 1,000 tiny bindings and writes 2 attributes.
• Keyed lists. Common prefix and suffix stay in place; an insertion or a removal in one place needs no key map; otherwise a map for the changed middle only, and LIS moves. The index (and object key) refs are only made when the item function declares them; a plain array is used as it is (reactive arrays are still read item by item). A list that is all its parent holds and loses every item is removed with one optional backend clear (textContent = ""), hooks in the usual order. Remove a row: script 0.25 ms vs Vue 2.4 ms.
• Fewer allocations elsewhere: on() without modifiers takes a direct path, the DOM listener remover is a bound function, rendering runs through runInScope (no closures per render), no empty class writes on fresh nodes. Memory after 1,000 rows went from 4.5 MB to below Vue's.

What is still slower, and why #

Where Roots is not the fastest of what was measured, and why, as far as that is known.

• Select against Vue Vapor: 0.89–0.94 in three sessions. Selecting a row is 0.085–0.095 ms of script in Roots: about 70 function calls on the way from the delegated listener through the handler and the selector to the render flush, most of them run once and cold, at roughly 1 µs each. The selector binding of round ten removed 19 of those calls and no measurable time. A prototype that wrote the class synchronously inside the handler measured 1.19–1.29 on select; it was rejected, because it breaks "all DOM writes of a tick happen in the flush". A shorter path from event to write is work for a later round.
• Level with Vapor, not ahead, on create, replace, partial update, create 10,000 and clear; level with Solid on create and create 10,000. On creation the remaining cost per row is known (exact): 74 function calls and 17 objects, of which the item's record with its tracked .value, one render effect for the label and the _ctx proxy between the template and the component's bindings are the larger parts. An inline render mode without that proxy, and a row whose item is the raw object, were measured as prototypes (1.03–1.05 each); the second was rejected on semantics (a watcher of the item alias would miss an identity change under a kept key), the first is deferred.
• Totals: Vapor 0.96, Solid level. With style and layout, Vapor's medians are 4% lower in both sessions and Solid's are 5–6% lower on replace, although Roots runs less script. Not explained; the rows have the same DOM (the fingerprints agree).
• Against hand-written code: with its row in a <template> the hand-written app creates 1,000 rows in 0.63–0.65× of Roots' script time, 10,000 in 0.76–0.79×, and does select, swap, remove and partial update in 0.42–0.68×, at 0.04–0.15 ms. The floor of this design for a row that binds nothing was measured at 1.13–1.15× of hand-written code; the rest is the bindings above. In totals the two are within 3–6%.
• Firefox (two sessions, see the table): replace is 0.69–0.84 of Solid's time, and the totals of swap and remove are 12–15% above every other app's, as they were in 0.3.2. Neither has been looked into. Homing template prototypes is off there; in WebKit it is on and its gain is not resolved (a small gain in one session, nothing resolved in another). Select in Firefox against 0.3.2 is not resolved either: level in five gate sessions, two timer steps slower in two.
• Three template patterns against Vue 3.5 (run-patterns.mjs, three sessions, each outside the band in one or two of them): text/fill 0.81–0.86, a row whose element holds text with interpolations, which Vue creates with fewer steps; attr/updateAll 0.81–0.85, replacing every item of rows with two bound attributes; if/updateAll 0.75–0.93 (and if/fill 0.87–0.91), rows that hold a v-if/v-else, where each Roots branch is a block with its own owner and effect. Nothing since round seven was aimed at them. In totals Vue is also 20% lower on prim/fill in two sessions, which is not explained.
• First render and size against the small frameworks. Solid, Preact, lit-html, Inferno and ivi render the bench app in 0.54–0.61× of Roots' time on localhost and 0.68–0.80× over the emulated network, from bundles of 4.4–10.2 KB gzip against 19.6 KB. About 82% of the bench bundle's gzip is a base every Roots app ships (a one-component app is 15.2 KB): the component instance, owners and scopes, the scheduler, event delegation, deep-ref proxies, the attribute rules of the security hardening. The measured cheap items (--error-codes: −1.1 to −1.6 KB gzip; feature flags for parts an app does not use, simulated at −2 to −19%) reach about 16 KB for the bench app; below about 9 KB for a hello world the component model itself would have to change. What holds: Roots is the smallest and the first to render of the frameworks with a full component model and deep reactivity measured here (Svelte 5, within 3% in size and level on first render; Vue Vapor; Vue 3.5).
• Memory against ivi and lit-html: 760 B of JS heap per row against 485 and 530, with the same number of objects as ivi (17.2 against 17.4) and more than lit-html (12.6). The loaded app's heap (1.32 MB) is the largest of the field after Vue 3.5's.
• The bundle has no compile hint, on purpose: measured on three apps, it helps one and slows one (round ten). The todo bundle spends 10.7 ms between its response and the first render where the hinted unbundled modules spend 2.8 ms; the bundle still renders first (12.3 against 14.8 ms) because it is one request.
• Totals are bounded by the browser. For create, replace, append, partial update, swap and remove, style recalculation and layout of 1,000–10,000 table rows are 80–97% of Roots' total, so the field's geometric means are within 0.96–1.29 of Roots' in totals (Preact 1.83). 2× over Vue on totals is not reachable for these operations by any framework.
• Not measured: cold renderer processes and repeat visits (HTTP cache, V8's code cache); phones; Safari itself (WebKit 26 was run through Playwright in the gate only). The field tables are Chromium; Firefox has two sessions with Solid and one with Vue. The frameworks other than Vue 3.5 were measured on the benchmark's row only, not on the template patterns or the kit. Vue Vapor is a release candidate.

Semantics notes #

What the speed work changed for app code and for backends, newest first, each checked against the code; the reference text is in docs/runtime.md, docs/templates.md, docs/build.md, docs/bundling.md and docs/CONTRACT.md.

Round ten (0.3.3) #

The owner's rule for this round: behaviour may change where a proof of concept is faster and the result is consistent and correct, and every change is listed. This is the list.

Templates and rendering:

• A fresh copy of a static template belongs to an inert document in Chromium and WebKit until it is inserted (ownerDocument.defaultView is null); in Firefox it belongs to the page's document as before. Code may rely on neither. Until insertion, URL-reflecting properties answer the unresolved attribute (a.href is "rel/x", a.protocol is ":"; also img.src, form.action): a function ref or a directive's created hook that reads them sees the raw value (read getAttribute, or the property in mounted). An <img> with a static src starts loading at insertion, not at copy. Unchanged from 0.3.2, because their templates stay in the page's document: templates with a custom element (a dash in the tag, or is), with a <video> or with an <audio> (WebKit selects no <source> for a media element copied in an inert document).
• The v-for item is the list's record, not a shallowRef. .value is tracked and read-only; isRef(item) is false. Index and key arguments are still refs. A template that assigns a v-for alias or a slot prop (@click="n++", row = other, --i) is compile error C254; in 0.3.2 it compiled, and for the item alias wrote the row's own ref (the row showed the value until the list next refreshed it). A property of the item (row.done = true) is writable as before. A hand-written render function that assigns item.value gets a TypeError.
• The list scan compares kept items with === when the item function takes one parameter: an item that changes between 0 and −0 under the same key no longer re-runs its readers. The list keeps the last keys array and a copy of the items (about two pointers per row); a record is 84 B (was 72 B).
• Handlers of static-template nodes in v-for rows are shared: one function per handler site and render of the list, called with (row, event). A function-expression handler is evaluated per event instead of once per row (visible only to code comparing the function's identity). Handlers that read the index or key alias or a destructured alias, empty handlers and handlers in slot bodies stay a closure per row.
• A selector class is written without a render effect (:class of the form f(selector(key)) in a keyed v-for), only when the callee is declared in the component's <script setup> as const name = createSelector(…) with createSelector an import. Any other callee (an import, a composable's result, a prop, a let, a plain function) is bound as a class effect as in 0.3.2, because it may be a ref whose selector is replaced later. The class is written at bind time and then in the render flush in creation order, like every binding. The key is taken at bind time.
• Compiled modules for DOM targets call new helpers (setElText, bindElText, bindClassEl, onEl, onWith, rowHandler, onRow, bindSelected), so a module compiled for web, pwa, ext, ios or android needs a runtime that exports them. The terminal target and a compilation without a target emit what 0.3.2 did. on with modifiers is onWith (same behaviour; on with a fourth argument still works). forBlock(source, render, key, single): single is the compiler's promise that every item is one host element.
• R307 and R308 have the same text and console output and are now raised through the DOM backend's own warn; they still do not reach the warnHandler.

Bundler and build:

• Minified bundles look different and behave the same, with one exception visible by reflection: a module-level const x = Symbol("roots.…") becomes Symbol() when the chunk does not export it and uses it only as a key or in an equality test. A symbol used as a value anywhere (inject(key)) keeps its description, so R206 names its key as before (docs/bundling.md).
• CLONE_BACKEND is true in bundles for DOM targets: clone no longer asks the backend for cloneNode / firstChild / isElement. A custom backend without them needs --no-bundle (CONTRACT §5).
• roots build --error-codes (opt-in, bundles only): a message becomes its code ([R208] ); error.code, the handler's code argument and the component trace are unchanged (docs/build.md).

Backends (CONTRACT §5, both optional): home(proto) and listenElement(node, event, handler, data, invoke?).

Round nine (0.3.1) #

• A ReactiveEffect is 96 B (was 88 B); one whose function declares onCleanup is 144 B (was 226 B). Its scheduler is fixed at construction (null counts as none). onCleanup and R106 behave as documented.
• New exports of runtime/reactivity.lisp for list bindings: trackDep, triggerDep, selectorBind, selectorUnbind; roots/runtime does not re-export them.
• Dialect: define-class takes (:constructor-fields t); (some? x) and (none? x) compile to x !== null and x === null (README, "Semantics to know").

Rounds four to seven (0.3.0) #

Production builds:

• DEV is false in roots build, bundled or --no-bundle; roots dev and roots run are development builds (DEV true, process.env.NODE_ENV "development"). Under DEV: prop validation (below), the R215 duplicate-key scan of a pure insertion and the check of a swap's two keys, and insert's R224 anchor check. The key map of a reordered middle still reports duplicate keys in production.
• Props are validated in development builds only. R202 (missing required prop) and R203 (wrong type, failed validator) are not reported by a roots build output and a validator is never called there, as in Vue's production build. Values, defaults, Boolean casting and R204 do not depend on it. A default factory runs at the first read that needs it (at mount in development, where validation reads every prop; possibly later in production), always with its component current.
• Unbundled DOM output carries a modulepreload link with integrity per statically imported module and starts each runtime, .vue, .ts and .lisp module under 128 KB with //# allFunctionsCalledOnLoad: an emitted module edited by hand no longer loads, as was already true of app.js.

Templates and rendering:

• Text runs. Adjacent text and interpolations are one text node kept by one binding (childNodes.length changes; textContent and the serialized DOM do not). An interpolation that throws takes its whole run with it, where it used to blank its own part. An element whose only content is a run has no text node while the text is empty.
• The key's text is written once. {{ row.id }} under :key="row.id" is not bound; an object used as key is ($.setText declines it and $.bindText binds it), and inside a slot that binds slot props nothing is taken for the key.
• Host primitives are cloned. A subtree of two or more Box, Text, Button, Image or Spacer elements is a static template; the static class and style of a v-for item's root are applied once to the prototype. A baked Image src therefore exists on one detached prototype per template, which the browser may fetch once (lowercase img already behaved this way).
• A bound attribute's first value is not written when it only says "absent": null, undefined, and false except for aria-*, data-*, contenteditable, draggable and spellcheck. Always written: class, style, value, to/replace on a Link, type, aria-hidden, textContent, fallthrough attrs, bindings on a component, and any binding the compiler marks as following an earlier write of the same name (bindAttr(node, name, getter, true): after a static attribute, an object v-bind or an earlier binding). Hand-written render code that calls setAttr and then bindAttr for one key has to pass that fourth argument itself. On the terminal backend a prop whose first bound value is false is absent from the node until its first update.
• Bindings that read nothing reactive are released after their first run and stopped; the effects of blocks, model and Link never are. A scope that released an effect stops its remaining effects in no particular order.
• One owner per list. Inside a v-for item's render, getCurrentScope() returns the item's record: a Scope (onScopeDispose works, the item's effects and nested content end with it), not an EffectScope with run and stop. A kept item whose value is the same object and that received no index or key ref is not touched by an update.
• Component instances. Components that were passed no attrs share one empty attrs / $attrs / useAttrs() object; $refs is created on first access; props and attrs views also throw R204 on Object.defineProperty, Object.setPrototypeOf and Object.freeze / seal / preventExtensions (delete already did).
• Class order corner case: a bound class whose first value is empty no longer claims the first position among a node's class sources; a source that appears before the bound class becomes non-empty is listed first ("x danger", not "danger x").
• R225 (new, warning): on was given a handler that is not a function, and ignores it. R224 (new, development): insert with the parent as its own anchor.
• Kit: pt and unstyled stay reactive for a part's class; which other attributes and handlers a part takes from pt is decided at setup (unchanged, now documented).

Reactive core:

• The shared onCleanup throws R106 wherever its effect is not the node collecting dependencies: after the run (as before), and now also during it inside untrack(...), inside a computed's getter and inside a watch getter. It used to register on the running effect there. This concerns only functions that reach onCleanup without declaring it (through arguments or a rest parameter) and effects made with cleanup: "run"; a function that declares the parameter keeps its own registrar, which works anywhere and at any time.
• effect(fn, { cleanup: "run" }) is new: the caller promises that fn calls onCleanup only during its run.
• Scopes do not own computeds. A computed created inside a scope is not stopped with it; it leaves its sources when its last subscriber does, and one that something outside the scope still reads stays alive.
• A parent scope stops its remaining children in no particular order once one of them has stopped on its own (the last sibling takes its slot), as in Vue; component owners are not affected.
• runtime/reactivity.lisp exports scopeRemoveEffect, batchCall, EffectBase and the type Scope for the component runtime; roots/runtime does not re-export them.

Backends (CONTRACT §5; all optional, the terminal and test backends work without them): isElement, collect, setTextContent, listen, adopt. Two requirements are new: a node fresh from createElement must have every unset prop absent (type and aria-hidden excepted), and host nodes carry the runtime's per-node state in one symbol-keyed property, Symbol("roots.nodeState"), visible to Object.getOwnPropertySymbols (a non-extensible node gets a WeakMap entry instead). The DOM backend keeps a primitive's base class, a Checkbox's inner nodes and the delegated handlers in symbol-keyed properties too.

Compiler and bundler:

• loop names. The variables a loop generates (result, end, the counter of repeat) carry the loop's number from the second loop of a compilation unit on (result2, end2), so two loops in one function no longer redeclare them; repeat's counter is _i, a name the body cannot mean.
• /* @__PURE__ */ is emitted on $.defineComponent({…}), on hoisted static templates and on defcomponent; (declaim (pure f)) and (pure (f …)) are new in the Lisp dialect.
• Minified names are letters only (52 letters, no digits), so that they cannot collide with the names Bun's bundler generates when it compiles a terminal app to one executable.
• B134 is an error for a named import of a name its module does not export, used or not (ESM refuses to link such a program; the unbundled modules would fail in the browser). ns.missing on a namespace import stays a warning and reads undefined.

The earlier rounds:

Round three (0.1.8): no behaviour change. An effect that re-runs itself more than 100 times in one flush is still stopped with R102 (now counted per flush with a mark and a map instead of two fields), and the benchmark's method changed as described under "Method".

Round two (0.1.7):

• Event delegation (DOM backend): see docs/runtime.md §6. Roots handlers on the path of an event run in native order among themselves, with currentTarget set; what differs from per-element listeners: a native listener added by your own code to an ancestor runs before the Roots handlers below it (and its stopPropagation() stops them), stopImmediatePropagation() does not stop the other Roots handlers of the same element, eventPhase is the bubbling phase, and an event dispatched on an element that is not in a document reaches no Roots handler. A handler that throws is reported like a throwing native listener, and the handlers above it still run.
• createSelector(source) is new (roots/runtime, docs/runtime.md §2).
• A computed that reads itself while it computes always reports R101. Before, a computed with subscribers took the read fast path and returned its stale value (and linked to itself).
• Compiler: module-level defvar/defparameter emit var instead of let (no temporal dead zone: a read before the definition gives undefined instead of throwing). In <script setup lang="lisp"> the bindings are var in setup() as well.

Round one (0.1.4); everything public behaved as before, internally observable details that changed:

• Schedulers (sync watchers, render effects) of the subscribers of a write are called right after the write's propagation, in subscriber order, as before; one that throws no longer stops the others (the first error is rethrown afterwards).
• An effect function that declares no parameter (it could only reach onCleanup through arguments or a rest parameter) gets a shared onCleanup that works while the effect runs; calling it later throws R106, and so does calling it during the run where the effect is not the node collecting dependencies: inside untrack, inside a computed's getter and inside a watch getter (round seven: no variable is kept for "the effect running now", so the registrar goes by the active node, and refuses any node that is not an effect running its own function). Functions that declare the parameter get their own, usable anywhere and at any time.
• R215 (duplicate keys) is reported when the list is reconciled with the duplicates (new items, or a reordered middle), not on every update.
• A flush that is aborted by an error resets the queued flag of the effects it drops (they could previously never be queued again).