Next.js vs React: When You Actually Need the Framework

Next.js gets recommended by default for almost any new React project now, and it's often the right call — but "often" isn't "always." Adding a framework designed around server-side rendering, routing conventions, and a deployment model has real costs when your project doesn't need what it solves.

What Next.js actually solves

• SEO for content-driven pages. Server-rendered or statically generated HTML is discoverable by search engines and AI crawlers without relying on client-side JavaScript execution.
• Initial load performance. Sending rendered HTML on first request avoids the blank-screen-then-populate pattern common in pure client-side React apps.
• File-based routing and API routes. Removes the need for a separate backend for simple data-fetching needs, and standardises routing conventions across a team.
• Image and font optimisation built in. next/image and next/font handle a meaningful chunk of the performance work covered in our React performance guide, automatically.

When plain React (or something even simpler) is the better call

• Internal dashboards and admin tools behind a login wall — SEO is irrelevant, and the added deployment complexity of SSR buys nothing.
• Highly interactive single-page apps where almost everything is client-side state anyway — a Vite + React setup is lighter and has a simpler mental model.
• Small marketing sites with 3–5 pages — a static site generator or even hand-built HTML with the site's existing design system can outperform a Next.js app on both simplicity and raw load speed for content that rarely changes.

The middle ground: hybrid rendering

Next.js's App Router makes it possible to mix rendering strategies within a single app — static generation for marketing pages, server rendering for personalised content, and client components for genuinely interactive UI. This is where Next.js earns its complexity most clearly: not as an all-or-nothing choice, but as a toolkit applied page-by-page based on what each route actually needs.

A real decision from a recent project

A SaaS client needed a public marketing site (SEO-critical) and an authenticated dashboard (SEO-irrelevant) as part of the same product. Next.js handled both well — static generation for the marketing pages, client-rendered React for the dashboard behind auth — without needing two separate codebases or deployment pipelines.

How to decide for your project

Ask two questions: does this page need to rank in search or be readable by an AI crawler without executing JavaScript, and does the first paint need to happen before any client-side code runs? If the honest answer to both is no — for example, an internal tool your team logs into — plain React is very likely the simpler, faster-to-ship choice.