Written by:
Last Published:
08 August 2026
•
Here is the confusion that sends most people to this page: Next.js vs React sounds like a choice between two rivals. It isn't. React is a JavaScript library for building user interfaces, and Next.js is a framework built on top of React that supplies the parts React deliberately leaves out: routing, server rendering, data fetching, caching, bundling and image optimisation.
Think of React as an engine. Beautifully made, and quite happy running on a bench. Next.js is the car built around it: the chassis, the gearbox, the wiring loom, all the unglamorous parts that turn an engine into something you can actually drive to work. You can build that car yourself. Plenty of teams do. The question is whether you want to.
That decision reaches well past the codebase. It sets your hosting bill, the shape of your hiring pool, how much of your stack is tied to one vendor, and how long it takes to ship the first page. So let's compare them properly: what each tool is, how they differ where it counts, and the Stack Fit Test, the four questions we run with clients to settle it.
First, the distinction everything else hangs on.
React is, like it says on the tin, a "JavaScript library for building user interfaces". It renders components and manages state. It does not decide how your app is routed, built, cached or served.
Next.js is a production framework for React. It makes those decisions for you and ships them as defaults.
Next.js sits on top of React, expanding what it can do and smoothing out the build. React does not need Next.js. Next.js cannot exist without React.
React is still the foundation of your app. The structure and the navigational mechanisms, the architecture, come from Next.js.
Most of the difference between the two comes down to one question: where do your pages get rendered?
Client-side rendering (CSR). The browser downloads a mostly empty HTML shell plus a JavaScript bundle, then builds the page. Nothing is visible until that bundle has downloaded, parsed and run. This is what a plain React app does by default.
Server-side rendering (SSR). The server builds the HTML and sends it complete. The browser paints something straight away, and the JavaScript takes over afterwards. It is one of the rendering modes Next.js gives you out of the box.
Static generation (SSG). The page is built once, at build time, then reused for every request, usually served from a content delivery network (CDN). Fastest of the three, because there is no per-request work left to do.
In Next.js that choice is made per route rather than once for the whole application, and honestly, that is most of what the framework buys you. Content that changes on a deploy cadence wants static generation. Data that changes per request or per user wants server rendering. Anything behind a login, where neither crawlers nor first paint matter much, can happily stay on the client.
One caveat, because this claim gets oversold. Server rendering improves time to first contentful paint, and it means crawlers receive complete HTML instead of having to run JavaScript to see your content. It does not make your app faster to use once it has loaded, and a server-rendered page is only ever as quick as the server answering the request.
Learn how to configure ESLint and Prettier in React.
React is a JavaScript library for building user interfaces, developed by Facebook and made open source in 2013. Components are the whole idea: they take input data and render a display. That output can be a plain "Hello World" or an interface assembled from rich, live data.
It is the most widely used front-end library in the industry, and the numbers are not close. More than 50 million weekly downloads on npm (npm trends). In the 2025 Stack Overflow Developer Survey, 46.9% of developers reported using it, more than double the share of Angular or Vue, and second only to Node.js across all web technologies. It has held that lead consistently.
You will find it behind dynamic websites, mobile apps through React Native, single-page applications, dashboards and visualisation tools. Facebook, Netflix, Reddit, BBC.com and Airbnb are all built with it.
One thing has shifted materially, though, and it changes how this comparison should be read. Create React App, the tool that used to set up a React project, was deprecated in February 2025, and React's own documentation now points new projects at a framework rather than a bare setup. React is still a library. But the official advice is that most teams should stop assembling the framework layer themselves.
React's strengths are exactly what you would expect from a library that does one job well. It is JavaScript, so developers who know the language are productive within days. Components are reusable, so you edit one and the change lands everywhere it appears. And because it stops cleanly at the view layer, you extend it with whatever you like, from state management to routing to data fetching. The ecosystem around it is the biggest in front-end development, which means almost any production problem you hit has already been solved by somebody, somewhere, at three in the morning.
The cost lives on the other side of that same sentence. Routing, data fetching, build configuration, rendering strategy: all yours to choose, wire together and keep running. Picking React alone does not dodge the decisions Next.js would have made for you. It hands them to your team, permanently, including the churn that dates third-party tutorials inside a year. That is a maintenance line item, not a setup cost. It is also the thing teams most often forget to price when they decide to stay on plain React.
Learn how to use TypeScript with Next.js.
Next.js is an open-source framework designed to work with React, created by Vercel. It runs on top of React to produce server-rendered applications, statically generated sites, or hybrids of the two, adding structure to React's functionality plus a fair amount of its own. It is opinionated, which is a polite way of saying it decides how your application is organised so you don't have to.
It is used for landing pages, content sites that live or die by search traffic, eCommerce stores, and web applications where load time is part of the product. Twitch, TikTok, Hulu, Binance, Nike and Notion all run on it. More than 9 million weekly npm downloads, and 21.5% of developers reported using it in the 2025 Stack Overflow survey, up from 17% the year before, and still climbing.
The Next.js framework earns its keep through defaults, and those defaults have moved a long way from the version most articles on this comparison still describe. The current release, Next.js 16, now ships Turbopack as its default bundler and has flipped caching from automatic to opt-in. Both are worth keeping in mind as you read the rest.
The App Router. Routing is the folder structure inside an app directory. A folder is a route segment, a page.tsx file inside it is the page, and layouts, loading states and error boundaries are files with reserved names. Your routing tree and your file tree are the same tree.
React Server Components. Components render on the server by default and ship no JavaScript to the browser unless you mark them as client components, drawing what the framework calls a client boundary: the line in your code where work stops happening on the server and starts happening in the browser. It is the biggest change to the React model in years, and the reason a Next.js page can query a database directly in a component with no API layer in between.
Data fetching and caching. Fetching happens inside components. Caching used to be aggressive and automatic; as of Next.js 16 it is opt-in, so a route is only cached when you say so. That change was made precisely because the old defaults caught people out. Static generation, per-request rendering and incremental revalidation, where a static page is quietly rebuilt in the background on a timer rather than at every deploy, are all just configuration on a route rather than separate architectures.
Streaming. Slow parts of a page get wrapped in a Suspense boundary, a marker that lets the rest of the page render while that section is still loading, then stream in when ready. One slow query no longer holds the whole page hostage.
Image optimisation. The next/image component resizes images, serves modern formats such as WebP and AVIF, and adapts them to the viewport. No separate media pipeline required.
TypeScript support. TypeScript builds on JavaScript by adding static types. Next.js supports it natively, typed routes included.
Built-in CSS handling. CSS modules, Sass and CSS-in-JS all work without configuration.
API routes. Backend endpoints live in the same project as the front end. Enough for authentication, webhooks and light integration work without standing up a separate service.
For how any of these behave right now, check the Next.js documentation, because the defaults have moved more than once.
Most of what Next.js buys you is decisions already made. Routing, rendering and data fetching are conventions rather than configuration, so a new page is a file, not a committee meeting. Rendering is set per route, so a marketing page can be static, a dashboard client-rendered and a product page server-rendered, all in one codebase. Crawlers and answer engines get complete HTML. Page metadata is declared in the route file itself rather than bolted on with a head-management library. Image optimisation, code splitting, font loading and prefetching are on by default instead of sitting on a performance backlog. And API routes mean smaller applications often need no separate backend at all.
Two things come with that, and neither is really a flaw. They are the price of the defaults. First, the opinions are not up for negotiation: the routing system is the file system, and if your application needs a routing model the framework cannot express, you end up working around it rather than with it. The caching model is the other example: genuinely powerful, and, before Next.js 16 made it opt-in, genuinely quick to catch out teams who assumed their data was fresh when it wasn't. Second, the learning curve is steeper than the marketing suggests. Server components, the client boundary and the caching layers are new concepts, not React with extra steps, and developers who know React well still need weeks to get productive. That ramp is a real project cost. Put it in the estimate rather than discovering it in the first sprint's slippage.
| React | Next.js | |
|---|---|---|
| What it is | A UI library | A framework built on React |
| Rendering | Client-side by default | Static, server, streaming or client, per route |
| Routing | Not included, add a router | File-system based, built in |
| Data fetching | Your choice of library | Built in, with an opt-in caching layer |
| Build tooling | You assemble it | Configured out of the box (Turbopack by default) |
| SEO | Needs work to serve crawlable HTML | Complete HTML by default |
| Backend | Separate service | API routes in the same project |
| Hosting | Any static host or CDN | Any Node.js host, with the smoothest path on Vercel |
| Best for | Embedded UI, apps behind a login, existing stacks | Content sites, eCommerce, anything search-dependent |
Back to the engine. Next.js does not replace React, it builds the car around it, using the same components, the same hooks (the functions React uses to hold state and side effects inside a component) and the same state libraries you were going to reach for anyway. Nothing you know about React stops being true.
Most comparisons stop at the feature table. If you are the one signing off the decision, these four points matter more.
A React single-page application is just static files. Park it on a CDN or in cheap file storage such as Amazon S3 for close to nothing. There is no server of your own to run.
Next.js needs somewhere to execute server code. On Vercel, the Pro plan starts at $20 per user per month, which now includes $20 of usage credit, and usage is where the bill actually moves: function invocations, bandwidth and image transformations all meter beyond that credit. Self-hosting on your own container platform removes the per-seat cost, but adds the operational work of running a Node.js service. That is a real line item if you do not already have that capability in-house.
The honest version? A small marketing site costs a little more on Next.js. A large one can cost considerably more, if nobody is watching what gets rendered per request.
Next.js is open source and can be self-hosted, so the lock-in is not a licence. It is that features tend to land on Vercel's platform first and work best there, and that the surrounding ecosystem of guides and defaults quietly assumes you are on it. Self-hosting is supported and well documented. It is also more work than the marketing implies.
If portable infrastructure is a stated requirement, run a self-hosted deployment early, not in the final month. The teams that get hurt here are always the ones who assumed portability and never once tested it.
React developers are the largest talent pool in front-end development, which makes them straightforward to hire and, just as importantly, to replace. Next.js developers are a subset of that pool. Smaller, growing fast. The subset who genuinely understand server components and the caching model is smaller again.
In practice this is a training cost rather than a hiring blocker. A competent React team can pick up Next.js. They just have to be given the time to.
Is moving an existing React app to Next.js a rewrite? No. Is it a weekend? Also no. Routing has to be remapped onto the file system, data fetching moves from the client to the server on the routes that benefit, and any code touching window or document has to be marked as running in the browser rather than on the server. Anything leaning on browser-only libraries needs checking.
For a mid-sized application, plan in weeks rather than days, and migrate route by route rather than in one heroic pass. If you would rather have someone map the risk before you commit, that is what our technical and UX audit exists for.
Rather than comparing feature lists, answer these four. We call it the Stack Fit Test, and it came out of having the same argument on project after project: the feature comparison almost never settles it, but these questions do. More often than not, three of the four answers point the same way.
If the Stack Fit Test returns yes on the first two and a credible answer on the third, use Next.js. If the first question is a flat no, React on its own is the simpler, cheaper choice, and choosing it is not a compromise.
Next.js vs React is a question of scope, not quality. React is the engine, and it is a very good engine. Next.js is the car built around it, and it earns its place when pages have to load fast, be visible to crawlers and answer engines, and render differently depending on the route.
Choose React alone for interfaces behind authentication, for UI embedded in something that already exists, and where your infrastructure is settled. Take AppTweak, an app-store intelligence platform we work with. Its homepage is a dense, data-heavy dashboard that users only reach after logging in, so no crawler needs to see it, and first paint matters far less than how quickly the charts become usable. So when we rebuilt it, we did it in React with TypeScript, Redux and Redux-Saga, and left the framework layer out. Loading time dropped by 80%, won by controlling the bundle and the rendering ourselves rather than by adopting server rendering the product didn't need. That is the React-alone case in a single project: the moment search and first paint stop driving the business, the framework you didn't add is one less thing to run.
Choose Next.js when organic search, first paint or content scale are commercial concerns, and you can absorb the hosting cost and the learning curve that ride along with them. For most public-facing products being built today, that is the more common answer. React's own documentation now says as much.
Next.js is built on React, so a solid grasp of React comes first. Components, props, state and hooks, the functions React uses to hold state and side effects inside a component, are all React concepts Next.js assumes you already have. Learn React, then learn what Next.js adds on top.
Neither is better, because they do different jobs. Next.js extends React with server rendering, routing and a caching model, which helps applications that depend on load speed and search visibility. React on its own is lighter and hands you full control of the surrounding stack. The right answer depends on the project.
For the first page a user sees, usually yes, because the HTML arrives ready to paint instead of waiting on a JavaScript bundle. Once the application has loaded, both run the same React code at the same speed. Next.js improves time to first paint, not runtime performance.
No. React runs perfectly well on its own. What Next.js gives you is a set of decisions already made, so you are not selecting and maintaining a router, a build setup and a rendering strategy yourself.
There is no single official React framework, but React's documentation recommends starting new projects with a framework and lists Next.js first among them. Create React App, the previous default, was deprecated in 2025.
A React single-page application is static files and can be hosted on a CDN for very little. Next.js needs a server runtime, so you are paying either a platform such as Vercel, from $20 per user per month plus usage, or the operational cost of self-hosting a Node.js service.
Expect weeks rather than days for a mid-sized application. Routing moves to the file system, data fetching moves server-side where it helps, and browser-only code needs client boundaries. Migrating route by route rather than all at once keeps the work shippable throughout.
Choosing between React and Next.js for something you are about to build? We have shipped both, and the answer usually turns on the Stack Fit Test above rather than on the frameworks themselves. Talk to our team and we will work through the four questions with you.
Content Writer and Digital Media Producer with an interest in the symbiotic relationship between tech and society. Books, music, and guitars are a constant.
Software Developer with a passion for creating products that bring good experiences to people's lives. Photography is another big passion and part of my life.
People who read this post, also found these interesting:
