$ cat choices/react.md
the call
For the web, React is the safe default: the ecosystem, the hiring pool, and the mental model are all there. But I'll almost always lead with React Native instead: same engine, and you get iOS, Android, and web from one codebase. Plain React is what I reach for when the surface really is web-only.
React won the web for real reasons: a component model that composes, a hiring pool that actually exists, and an ecosystem deep enough that most problems are already solved. For a web-only product it’s the boring, correct default. You spend your novelty budget on the product, not on betting against the grain of where the talent and the libraries are. Paired with TypeScript, it’s a stack a team can move fast in and still maintain.
Here’s the honest bias: I rarely reach for plain React first. If there’s any chance the product wants to be on more than one surface, I lead with React Native. Same React mental model, but react-native-web gives you the web app and the native apps from one codebase. Plain React is the right call when the surface genuinely is web-only and always will be, or when the web build needs deep, web-specific polish that the shared-codebase path would fight. Reaching for it just because “web means React” leaves the multi-platform leverage on the table.
People see React and React Native as different decisions; I see them as the same engine with a different reach. The call I actually make starts one level up: what surfaces does this need to live on? If it’s more than the web, and for most products it eventually is, I build for multiple platforms from the start and let one team cover all of them. Plain React is the answer to a narrower question, and a narrower question is the only time I ask it.— see: choices / react-native
Pick the tool that answers the real scope, not the one the category name suggests. “It’s a web app, so React” skips the question that matters (how many surfaces will this need?) and the cheapest time to answer it is before the first component, not after you’ve shipped a web-only app the business now wants on phones. Same engine, broader reach: lead with the broader one unless you have a concrete reason not to.
the gaps — what it costs even when it’s right
The ecosystem moves under you. React’s churn across routers, state libraries, and server-components shifts is real maintenance load. The default is safe; staying current in it is not free.
It’s easy to over-build the client. A pile of client state and effects where a server-rendered page would do is the common React failure mode: reaching for the heavy mental model when the page didn’t need one.
Choosing plain React can quietly foreclose multi-platform. Go web-only and the day the business wants a native app, you’re standing up a second codebase and team. That’s the exact tax leading with React Native was meant to avoid.