SYSTEM 01
REACT — STRUCTURE.
Four years of daily use. Mostly excellent, occasionally the wrong tool, and consistently misused in one specific way that causes most of the performance complaints I get called in to fix.
//What I use it for#
Interfaces with genuine state: dashboards, editors, multi-step flows, anything where what's on screen depends on several interacting pieces of data. React's real contribution isn't the virtual DOM, it's that it makes the relationship between state and output explicit enough to reason about. That's worth a great deal when a screen has fourteen possible configurations.
//The mistake I see most#
State placed too high in the tree. A single object holding everything at the root, so typing in one field re-renders a page of unrelated components. The fix is almost never a memoisation pass — it's moving state down to the component that owns it, which usually deletes code rather than adding it. I've removed hundreds of lines of useMemo from projects and made them faster.
The second mistake is treating effects as a general-purpose escape hatch. An effect that synchronises one piece of state with another is nearly always a sign that one of them should be derived instead. Deriving is free, cannot desynchronise, and doesn't have a dependency array to get wrong.
//Where I'd use something else#
Content sites with little interactivity — shipping a runtime to render mostly static markup is a poor trade, and server-rendered templates with a sprinkle of vanilla JavaScript are faster to build and faster to load. Also anything where I need precise frame-level control: a render loop belongs in a plain requestAnimationFrame callback writing to a canvas, not in a component's state.
React sits alongside TypeScript at the type layer and Next.js for delivery; the component conventions are written up under design systems.