Next.js or Plain React with Vite? Matching the Framework to Your Project

On plenty of React teams Next.js is the answer before anyone has asked the question. The docs are excellent, the ecosystem is huge, deployment is smooth, and there's a common belief that it makes sites faster and easier to rank, so starting every project with it feels like the safe call. A framework is still a tool with a specific job, though, and Next.js can add as much friction to the wrong project as it saves in the right one. What follows is a practical way to decide: what Next.js really solves (SSR, SEO, mixed rendering), where it clearly pays off, the common cases where plain React on Vite fits better, and how to put the choice to your team as requirements instead of preference.

What Next.js actually adds to React

Strip away the marketing and Next.js is mostly about how and where your React code renders. Concretely, it provides:

• Server rendering (SSR), build-time static generation (SSG) and mixtures of the two, layered on top of React.
• File-based routing, so the folder structure defines your URLs instead of a hand-written route table.
• A thin backend layer that ships with the frontend: API route handlers, middleware and edge functions, which lets one codebase serve a full-stack application.
• Close integration with modern hosting platforms, Vercel above all, for caching, edge delivery and deployment.

That list condenses into one sentence worth keeping in mind for the rest of the discussion: Next.js earns its place when initial load performance, SEO, and bringing frontend and backend concerns together under one framework genuinely matter to the project. Every scenario below is really a test of that sentence.

Projects where Next.js clearly pays off

Search visibility and first load are business requirements

Some products live or die by organic traffic and first impressions:

• marketing sites and product landing pages
• content-heavy blogs and documentation portals
• e-commerce storefronts that depend on search

For these, server rendering and static generation are not luxuries. The browser receives complete HTML before any JavaScript executes, so users see content sooner and crawlers can index real text rather than an empty root element. Next.js also lets you pre-render pages with their data, manage meta tags cleanly per route, and use Incremental Static Regeneration (ISR) to refresh content without rebuilding the entire site whenever something changes. Assembling the same capabilities around a bare single-page application is possible, but rarely as clean.

You want one framework for the whole stack

Consider projects such as:

• a small or medium SaaS product
• a dashboard backed by a handful of authenticated endpoints
• a typical web app where the same team owns frontend and backend

Next.js lets API code and React components live in the same project. You can write endpoint handlers in app/api (or pages/api if you are on the older Pages Router), use middleware for authentication checks, localization and redirects, and deploy the whole thing to any platform that understands Next.js, which includes Vercel but is not limited to it.

For a solo developer or a small team, that consolidation is valuable. There is no separate Node or Express server to wire up and no second deployment pipeline to maintain. Server logic sits beside the components that consume it, and the framework coordinates routing and rendering between them.

Public and private areas need different rendering

Many applications naturally split into two halves: largely static public pages such as the home page, pricing and docs, and dynamic signed-in areas such as a dashboard or admin console. Next.js handles that mixture well. You can statically generate content that rarely changes, render per-user pages on the server, and keep highly interactive widgets client-only where server rendering adds little. The real benefit is choosing the rendering strategy route by route, so you can tune performance for each part of the product without switching frameworks or maintaining two codebases.

Projects where plain React is usually the better fit

These cases are common, and they are exactly where teams tend to reach for Next.js out of habit.

Client-side apps nobody finds through search

Think of internal operations or analytics dashboards, admin panels behind a login, and tools where every user arrives directly at the app rather than from a search engine. In these products all data is fetched after the app loads, an empty initial HTML document is irrelevant because crawlers are not your audience, and the performance problems that matter are client-side ones: state management, data fetching and rendering efficiency.

Next.js brings server capabilities you will not use, a server runtime you do not need and extra concepts around routing and data loading. A React app built with Vite, Parcel or even a plain webpack setup is often faster to iterate on and easier for everyone to understand. If you want a refresher on what such a setup involves, see our walkthrough of a first React and Vite app.

A useful heuristic: when every important screen sits behind authentication and users reach it through a known URL or an app shell, Next.js is optional rather than necessary.

Widgets, component libraries and embeddable tools

Sometimes the deliverable is not a website at all. It might be an embeddable widget published to npm, a shared design system, or a single-screen tool that will be mounted inside someone else's application. What you ship is reusable UI, not pages, so routing, SSR, SSG and a prescribed folder layout solve problems you do not have.

A lean React build is the better choice here for three reasons. You can build and publish without working around framework conventions. The consumers of your package decide how and where it renders. And you avoid baking Next.js-specific assumptions into code that should run anywhere. If your project has no real pages, a framework organized around pages is the wrong starting point.

Routing that does not map to folders

File-based routing is convenient for many apps, but it is still a constraint. URL structure is bound to directory structure, certain advanced patterns require workarounds, and heavily data-driven routing can feel forced. If your application has deeply nested and highly dynamic routes, a navigation model that does not resemble a file tree, or unusual URL schemes dictated by business rules, React paired with a programmatic router such as React Router may serve you better. Defining routes in code gives you full control instead of bending your design to the framework's expected layout.

The question to ask is whether file-based routing makes your mental model simpler or keeps fighting it. If it fights, plain React is likely the better match.

Mostly static content with little interactivity

Next.js can produce static sites, but the output still includes the React runtime and the cost of hydration. For simple marketing pages, documentation with limited interactivity, portfolios and small content sites, that can mean shipping far more JavaScript than the pages require. Static site tools such as Astro, Eleventy or Hugo, or even hand-written HTML and CSS with a little JavaScript where needed, typically yield smaller payloads and simpler deployments.

In short, if a page behaves like a document rather than an application, a React meta-framework is more machinery than it needs.

Hosting that cannot run server code

Next.js is at its best when you can deploy to a platform that runs Node or serverless functions and you actually use SSR, edge functions or API routes. Your situation may be different: static-only hosting such as GitHub Pages, Netlify in purely static mode or S3 behind CloudFront; a policy that forbids long-running Node processes; or a budget where paying per serverless invocation is unwelcome.

In that world, a static React build from a tool like Vite is simpler: generate the assets, upload them, done. Next.js does offer a static export mode for this situation, but it gives up server-dependent features such as ISR, middleware and route handlers that need a server at request time, so check the current docs for exactly what is supported. If you find yourself using Next.js while never touching SSR, API routes or middleware, you are mostly using it as an elaborate bundler.

The team's experience is part of the decision

Technical fit is only half of the picture; your team's familiarity matters too. Suppose the team is comfortable with client-side React and single-page patterns, has little experience with SSR, streaming or data fetching in Server Components, and needs to deliver product features rather than invest in platform engineering. Adopting Next.js then means taking on:

• new mental models, including Server Components, server-side data loading and routing conventions
• operational complexity around deployment targets, caching layers and edge behavior
• more moving parts to inspect when rendering or hydration goes wrong

That investment can absolutely be worth it, but it is a real cost. For a small product or an internal tool, staying with a stack the team knows deeply is often the better call than adopting something because it feels more modern. If you are weighing the framework's newer features, our map of modern Next.js features and what each replaces is a good way to gauge how much new ground there is to cover.

A decision checklist for new projects

Work through these questions at the start of any React-heavy project:

1. Do you need SSR or SSG for SEO or first-load performance? If so, Next.js is a strong candidate; if not, plain React is perfectly adequate.
2. Is this a site made of real pages, or mostly an app shell? Many content pages point toward Next.js; a single-shell interface points toward a React single-page app.
3. Do you want a small backend living next to the frontend? If API routes and middleware in the same repository appeal to you, Next.js fits. If a dedicated backend already exists, whether in NestJS, Spring Boot, Laravel or something else, Next.js adds less.
4. Where will it be hosted, and on what budget? Being able and willing to pay for server processes or function invocations keeps Next.js on the table. If only static hosting is available, a lean React build is usually the better match.
5. What does the team know well today? If everyone is strong in React but only a few people understand SSR and Server Components, ask whether the project's requirements actually justify the learning curve.

None of this forces an all-or-nothing position. You do not have to standardize on Next.js for everything or rule it out entirely. The healthy stance is to treat it as one option in your React toolbox, chosen deliberately when its strengths line up with your needs.

Framing the choice for your team

If you are the person making or influencing this decision, avoid framing it as "Next.js is overkill", which sounds like a matter of taste. Anchor it to trade-offs the team can evaluate instead:

• "This internal dashboard gets little from SSR or SEO, so Next.js would add overhead without a clear benefit."
• "The component library has no pages or routes, so a plain React build setup suits it better."
• "Our hosting only serves static files, so most of what Next.js does well would go unused."
• "We will reach for Next.js on public, content-heavy products where performance and search matter, and keep plain React for internal tools."

Statements like these keep the conversation on requirements rather than trends, and they make it easy to revisit the decision if those requirements change.

Let the requirements pick the framework

The choice between Next.js and plain React is not about which is more modern; it is about which set of problems your project actually has. Server rendering, SEO, per-route rendering strategies and a colocated backend are real advantages when you need them and real overhead when you do not. Start from the requirements in the checklist above, factor in your hosting constraints and your team's experience, and let the framework follow from those answers rather than the other way around.