From Create React App to Next.js: Why the Ecosystem Actually Moved

Create React App (CRA) was, for years, the default way to start a new React project — one command, a working build setup, zero configuration. React's own documentation stopped recommending it, and the project is effectively deprecated. The reasons are the same gaps the rest of this pillar has walked through, one by one.

What CRA actually was, and wasn't

CRA solved exactly one problem: build tooling. Webpack config, Babel setup, dev server — all pre-configured, genuinely valuable at a time when setting that up by hand was a real barrier to getting started. It never had an opinion on routing, data fetching, or rendering strategy — every CRA app eventually reached for React Router, then its own data-fetching pattern, then discovered CSR's SEO and performance costs the hard way, on its own, per project.

The gap that actually mattered

Every one of the problems covered earlier in this series — no SSR/SSG, no file-based routing, no built-in image/font optimization — applied fully to a CRA app. CRA gave you a blank canvas; it never closed the gap between "blank canvas" and "production-ready app," and by the time most teams noticed, they'd already built enough app-specific logic on top of CRA's assumptions that migrating was a real, costly project — not a config change.

Why the ecosystem converged on Next.js specifically

Not because it was the only option (Remix and others solve overlapping problems) — but because it's maintained by Vercel with direct, continuous involvement from the React core team itself, meaning Next.js is frequently the first framework to ship support for new React features (Server Components, the App Router) as they stabilize. For a team choosing where to place a long-term bet, being close to the source of the underlying library's own roadmap is a real, practical advantage, not just a popularity signal.

The actual lesson

This is a case study in a pattern worth recognizing elsewhere: a tool that solves the *starting* problem well can quietly leave the *production* problems unsolved, and a team pays for that gap later, at a worse time, in a harder-to-fix way than if the production-shaped decisions had been made up front. That's the same reasoning behind planning before building, covered in this site's own "Six Planning Documents" post — the gap CRA left is a technology-specific instance of a much more general lesson.