Next.js uses React. The choice is how much application infrastructure you want a framework to provide, and what your team can operate confidently.
Start with the shape of the product
A public catalogue and a private operations console have different requirements, even when both use React components. List the pages that need to be discoverable, the interactions that need immediate feedback, and the data that must stay on the server. That inventory is more useful than choosing a tool from a popularity chart.
React provides the interface model. Next.js adds application conventions around routing, rendering, and server integration. React’s documentation recommends starting new applications with a suitable framework, while allowing a from-scratch setup when the constraints call for it. A client-rendered React application is an architectural choice, not a separate alternative to React itself.
Compare the responsibilities you are taking on
This table is a planning guide, not a ranking. Either approach can produce a good application when its responsibilities are understood.
Swipe the table to compare all columns →
| Decision | Client-rendered React setup | Next.js |
|---|---|---|
| Routing and loading | Choose and integrate the supporting tools | Use framework routing and rendering conventions |
| Public content | Plan how content is rendered and indexed | Plan server or static rendering alongside interactive parts |
| Data access | Usually calls a separately secured API | Can combine server-side data access with client interactions |
| Operations | A static frontend can have a simple hosting model | Runtime needs depend on the features you choose |
| Team ownership | More integration decisions stay with the team | More decisions follow framework conventions |
Keep interactive boundaries deliberate
A page does not have to be entirely static or entirely interactive. In the Next.js App Router, Server and Client Components have different responsibilities. Browser events and local interaction belong in client components; server-side work can stay outside the browser bundle. The boundary should follow the feature, not a habit of marking every file as client code.
For a product catalogue, the descriptive content and an interactive saved-items control can be designed separately. For an internal editor, much more of the screen may need browser state. Neither pattern removes the need to check authorization wherever protected data is read or changed.
Run a representative slice before committing
Build one real route containing authentication, a data request, a form, an error state, and the deployment path. Ask the team to make a small change to it. This reveals more about maintainability than an isolated benchmark or a polished starter screen.
Choose the approach whose tradeoffs fit the people maintaining the product. Record the reasons, including any constraints from an existing backend or hosting environment. Revisit the choice when those constraints change, rather than treating the first decision as a permanent rule.
