Interface · We run it ourselves
React is a JavaScript library that describes an interface as a tree of functions of state, and recomputes the parts of that tree whose state changed.
React is not a rendering technology, it is a decomposition technology — its value is that a screen becomes a set of named, independently testable units with declared inputs, and only incidentally that it updates the DOM. Most sites do not need that, because most sites have no state worth decomposing, and paying for React on such a site means shipping a runtime to a browser that will never call it. This site runs react 19.2.4 and treats it as a build-time authoring language: components compose the pages, and the browser mostly receives HTML.
01
The unit of reuse in React is a function with typed props, not a template with a convention. That distinction matters when a card, a table row and a page header must agree on how a service is displayed — the agreement is enforced by the compiler rather than by whoever edits the template next. On this site the same component renders inside the page and inside the Markdown twin path at /services/<slug>/md, and the two cannot drift without a type error.
02
Server Components move the default the right way round. Before React 19's server components stabilised, the question was which parts to make static; now the question is which parts to make interactive, and every component that does not answer it ships zero JavaScript. That inversion is the reason a component model became affordable for content sites at all — it is not a performance trick applied afterwards, it changes what the default build output is.
03
The cost is real and it is paid twice: bytes for the runtime, and time for hydration, during which the page looks finished but is not. A page whose only interactivity is a link and a scroll-triggered fade does not recover that cost. This site accepts it for a narrow set of components — motion is imported for animation, and the analytics client from @vercel/analytics is a browser component by definition — and refuses it everywhere else.
04
React composes with typed data far better than it composes with markup. The build gates on this site — scripts/check-schema.ts, scripts/check-markdown.ts, scripts/check-knowledge.ts — read the same TypeScript structures the components render, so a dangling @id in structured data or a route that disagrees with content negotiation fails the build rather than the page. That only works because the page is a function of data, not a document that happens to contain data.
05
Where the component model genuinely earns its cost is in applications with contested state: several views of the same record, optimistic writes, forms whose validity depends on other fields. Carfleet, a vertical operating system for car rental, and status-kvo-app both sit on Supabase behind a React interface, and there the argument is not about markup at all — it is that a client cache and a component tree let one record change once and every view of it agree.
06
React is a rendering model and nothing else. It has no opinion about data fetching, routing, caching or forms, which is why every React project in this inventory is really a Next.js project, and why the seahero build reaches for @mdx-js/react and next-mdx-remote-client to get content into components at all. Choosing React means choosing a second stack immediately afterwards; teams that describe React as their architecture have usually not noticed that they chose the framework instead.
07
The version number is not cosmetic. React 19 removed patterns that a large body of tutorial code still teaches — the old context API shape, string refs, legacy lifecycles, defaultProps on function components — and the ecosystem's answers lag it. Assume that any React snippet found online is written for a version this project no longer runs, and read the version's own migration notes before copying it.
An entry that cannot point at something you can open, run or read does not compile. That is a property of the type, not a promise in a paragraph.
Invariant
React stops paying for itself on any page whose state fits in the URL. A marketing site, a documentation set, a landing page — these get a runtime, a hydration pass and a build toolchain in exchange for authoring ergonomics that only the developer experiences, and the visitor pays for on a phone. Two further failure modes are structural rather than situational: React is very poor at animating between two different component trees, because unmounting is not a transition and the library has no memory of what was there before, which is why animation on this site comes from a separate library and not from React; and React's reconciliation cost scales with tree size, so a table of ten thousand rows will be slower than the same table rendered as innerHTML no matter how carefully it is memoised. A component model is also the wrong tool where the interface is a canvas rather than a document — the pakibus build in this inventory renders through three with a post-processing pipeline and a frame monitor, and putting React between the render loop and the GPU would add a diff of a tree with one node in it.