Next.js vs React

Every Next.js app is a React app. Components, hooks, and state work the same way. What Next.js adds is everything around React: a router, a server that renders pages, a build that splits code per route, image handling, and a place to put backend code. The React team itself now recommends starting new apps with a framework, and Create React App, the old default for single-page apps, has been deprecated.

So the real question is whether your app benefits from a server. If it does, a framework such as Next.js gives you one. If it does not, a single-page React app built with Vite is simpler and perfectly respectable.

Pick Next.js when people need to find the pages. A single-page app sends search engines and AI crawlers an empty shell and asks them to run JavaScript. Some do, some do not, and none do it as well as reading HTML. Next.js sends the finished page.

Pick it when first load speed matters, especially on phones. Server components render on the server and send less JavaScript, so a visitor on a slow connection sees content sooner.

And pick it when you want the backend close to the frontend. Server actions and route handlers can cover forms, webhooks, and simple APIs without a second service, and a CMS like Payload can run inside the same app.

Pick a single-page React app for a tool that lives entirely behind a login: an internal dashboard, an admin panel, or a client app for an existing API. Nobody searches for those pages, and once the app is loaded, a single-page app feels fast.

Pick it when you already have a backend in another language, such as FastAPI or Django, and want the frontend to be static files on a CDN. There is no Node server to run, patch, or pay for.

And pick it when the team is small and new to React. A single-page app has fewer concepts: no server and client component boundary, no server caching to reason about, and everything runs in one place.

Next.js is more to learn. The split between server and client components, data caching, and where code runs are real concepts a team has to understand, and mistakes show up as slow pages or confusing bugs. Most slow Next.js sites are slow because of what was put in them, not the framework.

It also needs somewhere to run. Static export removes the server, but most Next.js apps need a Node runtime on Vercel, Cloud Run, Firebase App Hosting, or your own machines. Next.js is open source and runs fine off Vercel, but that is a decision to make on purpose.

We default to Next.js because most of the products we build need both public pages that rank and an app people log into, and one framework for both is simpler than two. We have not shipped a standalone single-page React app on our work page; even our dashboards for the trading platform and Acasa Sentinel are Next.js. For a pure internal tool on an existing API, we would still consider a Vite single-page app and tell you if it fits better.