A rendering model, not an architecture
Technology
React is a rendering model: components, state, and a reconciler that turns state changes into DOM updates. It is not routing, data fetching, caching, or a build system, and every project has to answer those somewhere else. That is why we choose a framework and inherit React underneath, rather than choosing React and assembling the rest ourselves.
React sits under most of what we ship: marketing sites, commerce storefronts, dashboards, and our own site. It is our default because the component model transfers between those stacks and the talent pool is deep, not because it wins every technical argument. On a page with almost no client state, it loses one.
Why
Where React ends and your architecture starts
- A library with a framework shaped hole
React gives you components, state, and reconciliation. Routing, data loading, caching, and the build pipeline are somebody else's problem. React's own documentation now points new projects at a framework first, which is a fair admission that the missing pieces were never optional.
- The component model is the portable part
Props down, state up, effects at the edges: that model holds in Next.js, Remix, and React Native without changing shape. Our own site is Next.js with a Shopify Hydrogen storefront beside it, and Hydrogen is Remix underneath. Crossing that line means learning a router, not a new UI model.
- Rerendering is the cost model to learn
React rerenders more than it strictly needs to and expects you to notice when that matters. The usual cause of a slow page is one component near the top rerendering everything on every keystroke, and the fix is structural, not a memo call sprinkled on top.
- Most effects should not be effects
useEffect is for synchronizing with something outside React: a subscription, a browser API, a timer. Used for data fetching or derived state it produces double fetches, stale closures, and render loops. Most of the time the right move is to delete the effect, not to add a dependency to it.
- React defers the state decision to you
useState and context are where React stops. Whether server data belongs in a cache library, a client store, or a server round trip is your call, and it is the most expensive decision in the project. Subcore's dashboard runs live events through layered providers so views update in place.
- The API is stable, the advice is not
React itself changes slowly. The community consensus on how to fetch, style, and manage state has turned over several times around it. We keep those layers replaceable and the component core plain, which is why a codebase from a few years ago is still worth maintaining.
