Next.js vs React: which does your project need?
This comparison is slightly unusual because Next.js is built on React. React is a library for building user interfaces from components. Next.js is a framework that adds routing, server rendering, static generation, image optimisation and backend routes on top. The real question is whether your project needs those extras or whether they only add moving parts.
The short answer
Choose Next.js when public pages need to rank in search, load fast on mobile or live alongside an application in one codebase. Plain React, usually with Vite, is enough for apps that sit entirely behind a login, such as internal tools and dashboards. Next.js is still React, so the skills and components carry over either way.
Next.js vs React at a glance
| Criterion | Next.js | React |
|---|---|---|
| What it is | Full framework built on React | UI library; you choose routing and tooling |
| Rendering | Server, static or client rendering per page | Client rendering by default |
| SEO for public pages | Strong: search engines receive full HTML | Weaker unless you add server rendering |
| Routing | Built-in file-based routing | Add a library such as React Router |
| Backend code | Route handlers and server actions in the same app | Needs a separate API or backend |
| Hosting | Needs a Node.js runtime or a platform like Vercel | Static files on any host or CDN |
| Learning curve | Higher: server and client boundaries to learn | Lower: fewer concepts to start |
| Best fit | Websites, SaaS, content and e-commerce | Dashboards, internal tools, embedded widgets |
Choose Next.js when
- Marketing pages, blog posts or product listings must be found in search
- You want the public website and the signed-in application in one codebase
- First-load speed on mobile networks matters to conversions
- You need a few backend endpoints without running a separate server
- Content comes from a headless CMS or database and changes regularly
Choose React when
- The whole app sits behind a login and search visibility is irrelevant
- You are building an internal tool, admin panel or dashboard
- The frontend will be served as static files from a CDN or bundled into another product
- You already have a separate backend API and want the simplest possible frontend
- The team is new to React and should learn the core library first
Rendering is the real difference
A plain React app ships a mostly empty HTML page and builds the interface in the browser with JavaScript. That is fine once a user is signed in, but it means slower first paint and extra work for search engines. Next.js can render each page on the server or at build time, so the browser and crawlers receive real content immediately.
Next.js also lets you mix approaches: static pages for marketing, server rendering for personalised pages and client components only where interaction needs them. That flexibility is powerful, but it introduces concepts such as server components and caching rules that plain React does not ask you to think about.
Complexity and hosting
A Vite and React build produces static files that can be hosted almost anywhere for very little effort. Next.js features such as server rendering and route handlers need a server runtime, which means Vercel, a Node.js host or a container. Next.js can also export a fully static site, but you then give up the server features that are the main reason to use it.
A common hybrid
Many products I build use Next.js for the public site and the application together, because sharing components, authentication and deployment saves time. When a team already has a mature backend and a separate marketing site, a plain React app for the dashboard is often the cleaner choice.
Frequently asked questions
Is Next.js replacing React?
No. Next.js uses React for every component you write. Choosing Next.js means choosing React plus a framework around it, not instead of it.
Can I move a React app to Next.js later?
Yes. Components usually move across with little change. Most of the work is in routing, data fetching and deciding which parts render on the server.
Is plain React bad for SEO?
Not necessarily, as search engines can render JavaScript, but it is slower and less reliable than serving complete HTML. For pages where ranking matters, server rendering or static generation is the safer choice.
Still deciding?
Tell me about your product, users and constraints, and I will recommend the option that fits, even if it is not the one I use most.
Ask for a recommendation