React vs Next.js

React’s scope is deliberately narrow. Components describe what the interface should look like for a given state, hooks let them hold state and respond to change, and the renderer works out what has to change on the page and changes it. React does ship APIs for rendering on the server and for Server Components, and that sometimes muddies the comparison further. Those APIs are building blocks, though. Wiring them into routing, data loading, bundling and a production server is a substantial piece of engineering, and that wiring is what a framework provides.

Next.js provides it with strong opinions. Folders in the app directory become routes, layouts wrap the routes beneath them and persist across navigation, and every component is a Server Component unless it opts into the browser with a directive at the top of the file. Each route can be generated at build time, regenerated in the background, rendered per request or left to the client. Around that sit loading and error states declared as files, server actions for mutations, route handlers for endpoints, a metadata API for titles and social tags, and built-in handling for images and fonts. None of it is magic. All of it is code you would otherwise choose, integrate and maintain yourself.

This is also why the honest alternatives to Next.js are other ways of using React. The lightest is a single-page application built with Vite, with a router such as React Router or TanStack Router and a server-state library such as TanStack Query. Further along are other React frameworks: React Router’s framework mode, into which Remix was merged, and newer entrants such as TanStack Start. For content-heavy sites with small islands of interactivity, Astro renders pages to static HTML and hydrates only the React components that need it. What you are deciding is how much framework you want, and Next.js sits at the fuller end of that range.

One clarification saves a lot of confusion in team discussions. Learning Next.js is mostly learning React, plus a smaller set of server and framework concepts on top. The components, hooks, props and state are identical. What differs is where code runs, when it runs, and what the framework keeps between runs. That last part is where most of the difficulty sits, and it gets its own section below.

A client-rendered React application sends the browser an HTML document that is nearly empty: a root element, a script tag and perhaps a loading indicator. The content exists only after the JavaScript has downloaded, run and usually fetched data from an API. Every reader that does not execute JavaScript sees that empty document, and so does every reader that gives up before the work is finished.

Google does execute JavaScript. Its crawler fetches the page, queues it for rendering, renders it in a headless browser and indexes what it finds, and a well-built single-page application can rank. The risks are in the details. Rendering happens after crawling, sometimes considerably after. A failed API call, a blocked script, a timeout or content that only appears after a click can leave an indexed page with nothing useful on it. Titles and descriptions set by script after load are not treated consistently by every crawler that matters to you. And Google is the generous case. Link preview scrapers for chat and social platforms generally read the raw HTML and nothing else, and many other crawlers, including a number of those feeding AI answer engines, behave the same way.

Next.js removes that whole category of risk by sending finished HTML. The title, description, canonical URL and social tags are in the document, the content is in the document, and the reader does not have to run anything to see either. Server rendering does not make a page rank by itself. Content, internal links, performance and authority still decide that, and technical SEO is still a discipline of its own. What server rendering removes is the chance that a sound page is invisible because a crawler gave up on its JavaScript.

There is a middle path worth knowing about. A plain React application with a handful of public routes can prerender those routes to static HTML at build time, which covers a small marketing section without adopting a framework. It works well for a modest number of pages that change rarely. Past that point, or once pages depend on data that changes often, you are rebuilding static generation and incremental updates by hand, and the framework does that job better than most teams will.

A Vite build produces a folder of static files, and that folder is the whole deployment artefact. Any static host serves it, any CDN caches it, a storage bucket can hold it, and rolling back means pointing at the previous folder. There is no process to keep alive, no runtime to patch and no compute bill that grows with traffic beyond bandwidth. The server work, authentication and data, happens in a backend you run separately and would be running anyway.

Next.js offers more than one deployment shape, and the shape you choose decides what you get. A static export produces plain files much like a Vite build, and in exchange drops everything that needs a server: per-request rendering, incremental regeneration, server actions, request interception and the default image optimisation. The full framework runs as a Node.js server, which self-hosts well in a container on a virtual machine or a container platform. It can also run on platforms that map routes onto serverless functions and edge caches, where the operations work is lighter and the bill follows usage.

Vercel builds Next.js and runs the platform it works most smoothly on. New capabilities tend to arrive there first, and the features that involve caching, image optimisation and incremental regeneration need no configuration. Self-hosting is entirely viable, and some of it needs deliberate work: incremental regeneration across several instances needs a shared cache rather than each instance’s own disk, image optimisation consumes compute somewhere and should be budgeted, and a few features take more setup outside Vercel. Other hosting platforms support the framework too, and community projects such as OpenNext target several more. None of this is a reason to avoid Next.js. It is a reason to decide where it will run before the first route is written, rather than discovering the dependency on the day you want to move.

On cost, compare mechanisms rather than anybody’s current price list. Static output costs storage and bandwidth. Server rendering costs compute per request, whether you pay for it as a server you size yourself or as usage on a platform that bills for requests, execution time and data transferred. The detail that catches teams out is that a Next.js route can become dynamic because of a single call that reads a cookie or a header, at which point every visit is rendered on the server. Pricing models on every platform change, so check the current rate card, and read the build output on each release, because it states which routes are static and which are rendered per request.

The complexity in a plain React application is spread across decisions. Which router, which data fetching approach, how forms are handled, where shared state lives, how the folders are organised. Each decision is simple on its own, and together they define the architecture, which is why two plain React codebases can look nothing like each other. A team with a senior engineer who makes those choices once and writes them down does well. A team that leaves them open tends to make them several times, inconsistently, in the same codebase.

The complexity in Next.js is concentrated in fewer, harder ideas. Server Components cannot hold state or run effects. Anything that needs the browser sits behind a client boundary, and props crossing that boundary have to be serialisable, so you cannot hand a function from a server component to a client one the way you would between ordinary components. Libraries that assume a window object exists must be isolated. Then there is caching: memoised requests, cached data, cached routes and a client-side router cache, each with its own lifetime and invalidation rules, and defaults that have shifted between major versions. A large share of the hard Next.js bugs turn out to be caching behaving exactly as configured, which was not how anybody believed it was configured.

There is a characteristic failure that shows whether a team has the appetite for this. When boundary errors start to bite, it is tempting to mark components as client components until the errors stop. Follow that far enough and you have a client-rendered application with a server attached, more JavaScript than the plain React version would ship, and a hosting bill for rendering that nobody benefits from. If the team is not going to engage with the server half of the framework, plain React is the more honest choice.

On skills, any React engineer is productive in a Vite application from the first day. Next.js asks for some server thinking as well: HTTP caching, sessions and cookies, where secrets may and may not appear, what runs at build time and what runs per request, and how the runtime behaves under load. TypeScript helps on both sides and helps Next.js more, because types can follow data from a server query into a component without a separately maintained API contract in between. For handover, the framework’s conventions are a genuine asset: a Next.js codebase is recognisable to someone who did not write it, while a plain React codebase is only as legible as the decisions its authors documented.

Next.js has changed direction before, and it is reasonable to plan for it doing so again. The move from the Pages Router to the App Router was a rethink of routing, data fetching and rendering rather than an incremental update, and caching defaults have changed between major releases. The Pages Router is still supported and plenty of production applications run on it, but new capability is concentrated in the App Router. The release cadence is fast, upgrades deserve a planned slot with testing, and codemods handle the mechanical edits without covering changes in behaviour.

Lock-in follows the same layers. Your components are React and will run in any React environment. Your routing structure, layouts, server actions, caching calls, metadata exports and request handling are Next.js APIs, and moving a substantial App Router application to another framework means rewriting all of that. The framework itself is open source under the MIT licence, so what binds you is the framework and its conventions, not a vendor contract, and the hosting pull described above is a separate, smaller commitment that you control by deciding early where the application runs.

Plain React has a different maintenance profile. React itself changes its public API slowly and announces removals well in advance, and recent additions such as the compiler that handles memoisation automatically have been opt-in. The maintenance burden sits in the libraries you assembled around it, each on its own release schedule and occasionally abandoned by its maintainers. You get more upgrades, each usually smaller, and you can replace any one piece without touching the rest. Create React App is the cautionary example on this side: projects that depended on it now sit on an unmaintained build tool, and the fix is a move to Vite that is usually straightforward but still has to be scheduled and done.

Either way, this decision is cheaper to reverse than most framework decisions, because the component layer survives. That should lower the stakes of choosing. It should not encourage choosing casually, because the routing, data and deployment layers are where the rewriting happens, and those are the layers that differ.

This is one of the friendlier migrations in front-end work, because both sides are React. Components, hooks, styling and most client-side logic move across unchanged. What changes is routing, data loading, environment configuration and the deployment pipeline, and those can be moved gradually rather than in one release.

Moving a plain React application to Next.js usually starts by running the existing application inside Next.js as it is: a single catch-all route renders the whole single-page application on the client, so the product behaves as it did before, now running on the new framework. From there, routes move to file-based routing one at a time, public pages move to server rendering or static generation first because that is where the benefit is, and client-side data fetching is replaced with server-side loading where it pays for itself. Expect friction from libraries that assume a browser, environment variables that need renaming because the two tools expose them to the browser differently, and authentication that has to be understood on the server for the first time.

Moving the other way happens too, usually when a team realises it adopted Next.js for an application that never needed a server: everything is a client component, nothing is public, and the server exists only to be operated. Leaving means choosing a router, replacing file-based routing with route definitions, moving any server actions and route handlers into a proper API, and replacing the framework’s handling of images, fonts and metadata. It is contained work, and for an application with no public pages it can reduce hosting cost and operational load considerably.

Before migrating in either direction, check whether the complaint is really about the framework. A slow Next.js application is more often a caching or dynamic rendering problem than a framework problem, and a profile will tell you which. A plain React product with poor search visibility frequently needs only its public pages split out into a separately rendered marketing site, while the application stays as it is. Both of those fixes cost a fraction of a migration and solve the problem people actually have.