Next.js vs React

When to choose Next.js

Choose Next.js when the app has a public surface that has to render fast and rank in search (marketing pages, e-commerce, docs, content sites), when you want server side rendering, image optimization, routing, and a data-fetching model out of the box, or when you want one deploy target (usually Vercel) instead of stitching together your own stack. It is also the safer default for a small team that cannot afford to maintain custom build tooling. When hiring a Next.js developer, look past "I know React" and probe the App Router specifically: the Server Components vs Client Components boundary ("use client"), where data fetching actually runs, caching and revalidation (this is where most people get burned), and route handlers or Server Actions. Someone who has only used Next.js as "React with file-based routing" will write client components everywhere and lose the framework's whole point.

When to choose React

Choose plain React (with Vite, or embedded in an existing app) when you are building something behind a login where SEO does not matter (dashboards, internal tools, admin panels, a widget that mounts inside another site), when you need full control over the build and routing rather than the framework's opinions, or when you are shipping a component library or SDK that other apps consume. React alone is also lighter to reason about, since there is no server rendering layer or caching model to fight. When hiring a React developer, focus on fundamentals that outlast any framework: state management and when to reach for context vs a store, useEffect and its dependency arrays, render performance (memoization, reconciliation, avoiding needless re-renders), and how they handle data fetching and caching in the client (React Query or similar). A strong React developer will pick up Next.js in a week; the reverse is not always true.

The bottom line

It depends, mostly on whether unauthenticated users need to see server-rendered HTML and whether you want the framework to make infrastructure decisions for you. If you have public, SEO-sensitive pages or want a batteries-included deploy, Next.js earns its complexity. If you are building an authenticated app, an internal tool, or a reusable library, plain React with Vite is simpler, cheaper to host anywhere, and easier to hire generalists for. Neither is a universal winner, and picking Next.js does not lock you out of React skills since every Next.js developer is a React developer underneath.

Frequently asked questions

If we start with React and later need SEO, how painful is migrating to Next.js?

Moderate, and it depends on how you wrote the React app. Your components, hooks, and business logic mostly carry over untouched. The work is in the parts Next.js takes over: routing (React Router to file-based routing), data fetching that now has to be server-aware, and untangling anything that assumes a browser (direct window access, client-only libraries). Teams routinely do this migration, but budget it as a real project of weeks, not an afternoon, and expect the caching model to be the part that surprises people.

Is Next.js actually faster than a React SPA, or is that marketing?

It depends on the metric. For first paint and SEO on public pages, server rendering genuinely wins because the browser gets real HTML instead of a blank div waiting on a JS bundle. For an app the user has already loaded and logged into, a well-built React SPA can feel just as fast or faster, since there is no server round trip per navigation. Next.js also ships more framework code, so a badly built Next.js app (client components everywhere, no caching) can be slower than a lean React SPA. The tool sets the ceiling; the developer decides where you land.

Which has the bigger hiring pool, and does Next.js cost more to staff?

React has the larger raw pool, since every Next.js developer knows React but not vice versa, so hiring for plain React gives you more candidates and usually a lower rate. Next.js narrows the pool to people who understand the App Router and rendering model well, and those people command a premium, but you are also buying productivity because the framework replaces work you would otherwise pay someone to build and maintain. On hosting, plain React is cheaper and portable (static files on any CDN), while Next.js runs best on infrastructure that supports its server features (Vercel or a comparable setup), which is a real recurring cost to factor in.