Next.js vs React: What Should You Choose in 2025?

Every few months someone asks us: "Should we use Next.js or just React?" It is a fair question but it rests on a false premise — Next.js is React. What you are really asking is whether to use React alone (as a client-side SPA) or React with Next.js as a full-stack framework on top of it.

The answer in 2025 is almost always Next.js, but understanding why will help you build better applications regardless of which path you choose.

**React as a standalone SPA**

When you reach for Create React App, Vite, or a bare Vite + React setup, you are building a Single Page Application. The server sends one HTML file with a blank div and a JavaScript bundle. The browser downloads the bundle, executes it, and renders the UI. This approach has been the dominant pattern for internal tools and dashboards for years.

SPAs are great when SEO does not matter (logged-in dashboards, internal admin panels, tools behind auth), when you need maximum client-side interactivity, or when your backend is already a separate API that your team manages independently.

The major weaknesses of SPAs: poor Core Web Vitals (especially LCP) because content only appears after JS executes, no server-side rendering so search crawlers often see empty pages, and no built-in routing, image optimisation, or API layer — you wire all of this yourself.

**What Next.js adds on top of React**

Next.js 15 with the App Router gives you a complete framework on top of React. The key additions that matter in 2025:

Server Components: React components that render on the server and send finished HTML to the browser. Zero JavaScript shipped to the client for server-only UI. This is the biggest paradigm shift in frontend development in the last five years and Next.js is the primary way to use it in production.

Multiple rendering strategies per page: Static generation for content that does not change, server-side rendering for personalised pages, and Partial Prerendering (PPR) — stable in Next.js 15 — which statically generates a shell and streams dynamic content in. You can mix strategies within a single route.

Built-in image optimisation via next/image, automatic code splitting, the Link prefetching system, and Turbopack as the default bundler (dramatically faster local development in 2025).

The App Router file system: pages, layouts, loading states, and error boundaries all co-located. Route groups and parallel routes eliminate entire categories of routing complexity.

**Performance: the real gap**

In 2025, the performance gap between a well-optimised Next.js app and a React SPA is not subtle — it is significant. Google's Core Web Vitals directly affect search rankings, and SPAs consistently score worse on LCP because content is blocked behind JavaScript execution.

For a content-heavy page, a Next.js Server Component renders fully on the server and ships pre-rendered HTML. First Contentful Paint and LCP fire as soon as the HTML arrives. No JavaScript hydration required for the static parts. The difference in real-world Lighthouse scores can be 30–40 points.

For a logged-in dashboard where SEO does not matter, the gap narrows. A well-built Vite SPA and a well-built Next.js app with client components will feel similar in use — though Next.js still wins on routing, streaming, and infrastructure defaults.

**When to use a plain React SPA in 2025**

There are still valid cases for a React SPA without Next.js: you are building a purely internal tool that lives behind auth with zero public-facing pages, your team has an existing API and wants maximum separation between frontend and backend, you need an Electron desktop app (React + Vite is a natural fit), or your deployment target does not support Node.js server execution.

For everything else — public marketing sites, SaaS dashboards that also need public pages, e-commerce storefronts, content platforms — Next.js is the correct choice. The SSR, caching, and image optimisation capabilities alone justify it.

**The App Router learning curve**

Next.js 15 with the App Router is meaningfully more complex than the Pages Router or a plain React SPA. The distinction between Server Components and Client Components trips up almost every developer the first time. "use client" is not a switch that makes a component interactive — it marks the boundary where the client component tree begins.

The mental model shift: think about what needs to be interactive on the client versus what can be rendered once on the server. Fetch data in Server Components, handle user events in Client Components. Keep client components as leaves in the tree, not roots.

**Our recommendation for new projects in 2025**

For any new project at HN, we default to Next.js 15 with the App Router. The Server Component model, PPR, and the built-in infrastructure capabilities pay for the learning curve within the first two weeks of a project.

The only exception: if a client already has a separate backend team running an API and wants a completely decoupled frontend, we will use Vite + React for the dashboard layer and build the public-facing pages in Next.js as a separate app sharing the design system.

React alone is still a fantastic tool. But in 2025, Next.js is simply the more complete, more performant, and more production-ready way to build with React in most scenarios.