What Is Next.js, and When Should You Use It?

What it adds to React

React renders components and stops there. Next.js supplies the rest of an application:

• Routing from the file system: a file in the app or pages directory becomes a URL.
• Rendering choices per page: static at build time, server-rendered per request, incrementally regenerated, or client-rendered, so a site can be mostly static with dynamic exceptions.
• Data fetching integrated with rendering, on the server where possible.
• Server components, which render on the server and ship no JavaScript to the browser, leaving only the interactive parts as client components.
• API routes and server actions, so back-end logic lives in the same project.
• Image, font and script optimisation built in: responsive images, self-hosted fonts, deferred third-party scripts.
• Middleware at the edge for redirects, rewrites, authentication checks and localisation.
• A build system producing an output that deploys to Vercel with no configuration, or to any Node host or container with some.

Released in 2016 and now the most used React framework by a wide margin, it is what "a React app" usually means in practice.

The App Router and server components

Next.js 13 introduced the App Router alongside the older Pages Router. The App Router is built on React Server Components: by default every component renders on the server, fetches its own data there, and sends HTML plus only the JavaScript needed for components explicitly marked as client components. The result, done well, is pages that are fast to load and fast to become interactive because there is far less to hydrate.

The model takes learning. The boundary between server and client components, what can and cannot be passed across it, caching behaviour, and the differences from the Pages Router have been the main sources of confusion since the change. Teams starting fresh should use the App Router; teams with Pages Router applications can migrate incrementally or stay.

Hosting

Next.js is developed by Vercel and runs best there: every feature works with zero configuration, previews deploy per branch, and edge middleware and image optimisation are native. It also runs on Netlify, Cloudflare, AWS Amplify, Render and others through adapters, or on any server or container with Node, where a few features need manual setup. Fully static exports run anywhere. The dependence on Vercel is a legitimate consideration and it is not lock-in; it is a default that is convenient to accept and possible to leave.

What it costs

Complexity. Next.js is a large framework with its own conventions on top of React's, and the App Router added a new mental model. A production Next.js application is a serious codebase to maintain and to hire for.

Build and infrastructure. A build step, a Node runtime for anything not static, and, for the full feature set, a platform that understands the output.

Churn. Major versions have changed conventions substantially. Keeping an application current is ongoing work, and the ecosystem's advice ages quickly.

Weight for simple sites. A marketing site built in Next.js carries React's runtime and the framework's machinery to deliver pages that could have been static HTML. Server components reduce this considerably, but the simplest site still ends up heavier than a zero-build static one.

When to use it

A React application with accounts, data and interactivity: Next.js is the default and the sensible one. The routing, rendering and data layers are what the application needs, and the ecosystem supports it.

A content site built by a React team, particularly one sharing components with a product: the App Router with static generation produces fast, crawlable pages, and the team keeps one stack.

A product plus its marketing site in one codebase, where the marketing pages render statically and the application renders on demand.

Anything that needs server rendering, per-page rendering choices and edge middleware and whose team knows React.

When not to

A brochure or marketing site with no application behind it and no React team: a static site generator, or plain HTML, is faster, simpler and cheaper to keep. A team whose skills are in another ecosystem: Nuxt for Vue, SvelteKit for Svelte, Laravel or Django for server-rendered applications with light interactivity. A project that will not be maintained: Next.js's pace of change punishes neglect.

The decision

If the project is a React application, use Next.js unless there is a specific reason for a peer. If it is a website, ask whether a React application will ever sit behind it; if yes, Next.js is reasonable, and if no, something simpler will serve better. The structure of a scalable Next.js project is a separate question once the choice is made. If you are weighing it for a specific build, book a call.

Common questions