React

The incumbent this spoke had gone thirteen pages without naming. Coverage edge 4 put it plainly: not one of React, Vue, Svelte, Solid or Angular was paged, so the spoke could describe the ends of the stack and could not place anything against the norm. astryx is a design system built on a reconciler, opentui ships one for the terminal, and both were being described against a baseline the corpus did not hold. Read from react.dev (T1, first-party).

Render and commit

The docs give the model in three steps — trigger, render, commit — with the kitchen metaphor: components are cooks, "React is the waiter who puts in requests from customers and brings them their orders."

"Rendering is React calling your components." That sentence is the whole reconciler in one line. A render is triggered either by the initial mount or by a state update in the component or an ancestor; React then calls the component function, recursing into whatever it returns. Rendering must be a pure calculation — same inputs, same output, no mutation of anything outside.

Commit is where the DOM is touched, and the rule that matters is: "React only changes the DOM nodes if there's a difference between renders." On mount it is appendChild() for everything; on re-render it is the minimal operation set. The browser repaints afterwards. This is why a re-render does not clobber what you were typing in an <input> — nothing about that node differed, so nothing was written.

The cost model follows directly, and it is the one flutter-performance-200-hours describes from the other side: calling components is cheap and frequent, touching the surface is expensive and rare, and a framework's performance story is mostly about how much of the first it can do without incurring the second. Every reconciler in this spoke is a different bet on that trade.

The part that is a procedure, not a library

"Thinking in React" prescribes five steps, and two of them are unusually mechanical for framework documentation.

What counts as state — three disqualifying tests, applied in order:

• Does it remain unchanged over time? Not state.
• Is it passed in from a parent via props? Not state.
• Can you compute it from existing state or props? "If so, it definitely isn't state."

Where state lives — an algorithm rather than a principle:

1. Identify every component that renders something based on that state.
2. Find their closest common parent.
3. Put the state there, or in some component above it — and if no component makes sense as the owner, create one that exists solely to hold it.

That is a placement rule derived entirely from who reads the value. It is worth setting against the answer in ../frontend-architecture-wiki, where design-system's neighbours argue that features own their state and that ownership boundaries are what large applications actually fail on. React's rule knows nothing about features, teams or domains; it knows the read set. Two different answers to "who owns this state," and the spoke should not assume they agree — the closest common parent of everything that reads a value is frequently in a different feature from the one that conceptually owns it.

The remaining three steps: break the mockup into a component hierarchy (splitting on separation of concerns, CSS class boundaries, or design layers), build a static version with props and no state at all, then add inverse data flow by passing setters down as props.

What it gives the spoke

A baseline. ui-framework can now say what the norm is when it describes a departure from it, and the reconciler vocabulary in astryx and opentui resolves to something.

And the second member arrived on 2026-08-22, which qualified the baseline. svelte does the same job with no reconciler at all: a compiler works out at build time which DOM depends on which state, so nothing re-runs a component and nothing diffs a tree. "Rendering is React calling your components" turns out to describe React rather than the field. Read this page as one of two mechanisms, not as the norm the others depart from.

And a number arrived on 2026-09-03. js-framework-benchmark runs React 19.2 and Svelte 5.42 as implementations of one specified app. React is within a few milliseconds on almost everything and 7× slower on one operation — swapping two rows in a keyed list, 89.9 ms against 12.6 — which is the reconciler's cost made visible: the diff has to establish that almost nothing changed, and that proof is the price. Its transfer size is 51.4 KB brotli against Svelte's 9.7. Worth noting what does not fix it: react-compiler-hooks measures 90.4 ms on the same swap. The compiler memoises components; the reconciler is still there.

Related

ui-framework · svelte · js-framework-benchmark · strawberry-react-to-svelte · astryx · opentui · design-system · flutter · flutter-performance-200-hours · agent-ready-ui · synthesis