How the two relate
React is a library for building user interfaces from components. By itself it does not decide how pages are routed, where they are rendered or how data is fetched. A React application built without a framework is usually a single-page application. The browser downloads the code, and the interface is built on the visitor's device.
Next.js is a framework that uses React and adds those decisions. It can render pages on the server, generate them ahead of time, or render them in the browser, page by page. It also includes routing, image handling and a place to write server code. Choosing Next.js is still choosing React. Your components and your team's skills carry over.
The two options at a glance
| React, as a single-page application | Next.js | |
|---|---|---|
| Where pages are rendered | In the browser | On the server, at build time or in the browser, chosen per page |
| First load | The browser must download and run the application before content appears | Content can arrive as ready HTML |
| Search visibility | Depends on search engines running your JavaScript | Content is present in the HTML that is served |
| Hosting | Static files on any web host or CDN | A Node.js server or a platform that supports it. Static export is possible for some sites |
| Backend | A separate API is required | Server code can live in the same project, or call a separate API |
| Conventions | You choose routing, data fetching and structure | The framework sets them |
| Upgrades | You upgrade the libraries you chose | You follow the framework's releases, which can change conventions |
When each one fits
Choose React alone when
- The whole application sits behind a sign-in, such as an internal dashboard or an admin tool
- Search engines never need to see it
- It behaves like desktop software, with heavy client-side state
- A separate backend and API already exist
- It will be embedded in another shell, such as a desktop or mobile wrapper
Choose Next.js when
- Public pages must be found in search and shared with previews
- First load speed matters, for example on marketing or commerce pages
- One product mixes public pages with a signed-in application
- You want server code and interface code in one project
- Content comes from a CMS and pages should be generated from it
What changes for an enterprise team
In a larger organization the framework choice affects more than the code. These are the points that security, infrastructure and architecture teams usually raise.
| Concern | React single-page application | Next.js |
|---|---|---|
| Security review | No server of its own. The API carries all the risk | Server rendering and server code add a surface that must be reviewed and patched |
| Authentication | Tokens handled in the browser, checked by the API | Sessions can be checked on the server before any page is sent |
| Infrastructure | Fits any static hosting and existing API gateways | Needs a runtime. Confirm it fits your cloud, containers and deployment standards |
| Caching | Static files cached at the edge | Several cache layers that the team must understand, or stale pages follow |
| Team structure | Clear split between frontend and backend teams | Frontend engineers write some server code, which changes ownership |
| Vendor dependence | Low | Runs anywhere Node.js runs. Some features work most smoothly on particular hosting platforms, so test on your own |
Neither column is safer in general. A single-page application moves all responsibility to the API. Next.js adds a server that must be operated. Decide with the people who will run it.
A worked example
One company, two applications
An insurance company, invented for this example, starts two projects in the same quarter.
- A claims handling toolUsed by staff only, behind company sign-in, with dense screens and long sessions. An API already exists.
- DecisionReact as a single-page application. Nothing needs to rank or load instantly for strangers, and static hosting fits the security model.
- A customer site with quotes and policy accountsPublic product pages that must be found in search, a quote journey that must load fast on phones, and a signed-in area for policyholders.
- DecisionNext.js. Public pages are served as HTML, the account area is rendered for the signed-in user, and both share one component library with the claims tool.
The same team used both, and shared its design system between them. The choice was made per application, by who uses it and how they arrive.
A checklist to decide
Tick what is true for your application. Ticks in the first four point to Next.js. Ticks only in the last four point to React alone.
Framework checklist
0 of 8 checkedWhat to do next
Decide per application, not per company, and involve whoever will host and secure it. Our Next.js development and React development pages describe how we work with each, and enterprise dashboards covers the signed-in case.
If you are choosing for a specific project, tell us who uses it and how they arrive. We will say which we would pick and what we would check first.
Common questions
Is Next.js replacing React?
No. Next.js is built on React and needs it. What has changed is that the React documentation itself now points new projects toward a framework, and Next.js is one of the most widely used. A React application without a framework remains a valid choice for tools that live behind a sign-in.
Can search engines index a React single-page application?
Google can render JavaScript, so content in a single-page application can be indexed. It is processed in a second step, and other search engines and social previews may not run scripts at all. When search visibility matters commercially, serving the content as HTML removes that dependency.
Can we move from a React application to Next.js later?
Yes, and components usually move with little change. The work is in routing, data fetching and authentication, which a framework handles differently. It can be done area by area. It is easier when the original application kept data access separate from the interface.
Does Next.js lock us into one hosting company?
Next.js is open source and runs on any Node.js server, in containers or on several cloud platforms. Some features are most convenient on the platform of the company that maintains the framework. If independence matters, state your hosting target at the start and test the features you plan to use on it.
