nextjs.org

Next.js is a React framework for building full-stack web applications. React provides the component model for user interfaces; Next.js adds routing, rendering, data access conventions, server capabilities, compilation, bundling, caching, and production-oriented tooling.

The primary subject is the framework, not its domain. nextjs.org is the official website where visitors can find maintained documentation, guides, community links, and information about the project.

Next.js is most relevant when a team wants to build with React while supporting more than a browser-only interface. One project can contain prerendered pages, request-time responses, server-side data access, API-style endpoints, and interactive components that run in the browser.

What Next.js adds to React

React helps developers describe interfaces as components, but it does not prescribe a complete application architecture. Next.js supplies conventions for mapping files to routes, deciding where code executes, loading data, producing responses, and preparing an application for deployment.

Its value is therefore broader than server-side rendering. A Next.js application may use several rendering and delivery methods, sometimes within the same project. The framework coordinates those methods around React rather than forcing every route into one model.

A useful summary of the division is:

• React defines components, state, props, and interface composition.
• Next.js defines routes, layouts, rendering choices, server entry points, and build behavior.
• The application defines its data rules, client boundaries, cache policy, and deployment requirements.
• The hosting environment determines which runtime features are available and how they operate.

This separation matters when comparing Next.js with a React client application, a static-site generator, or another web framework. The framework offers a wide range of capabilities, but a project benefits only from the capabilities it uses well.

Server and Client Components

In the App Router, layouts and pages are Server Components by default. Server Components execute in a server environment and can perform server-side data work without sending their component implementation to the browser.

Client Components are used when part of the interface needs browser state, event handlers, effects, or browser-only APIs. Developers mark a client boundary with the use client directive, and components below that boundary become part of the client-side module graph.

Question	Server Component	Client Component
Where does its component logic execute?	In the server rendering environment	In the browser after being included in the client bundle
Can it use browser state or click handlers?	No	Yes
Can it directly use browser-only APIs?	No	Yes
Is its component code sent to the browser?	Not as client component code	Yes
Typical role	Data-backed content, layouts, and server-side composition	Forms, menus, editors, filters, and other interactive controls

A route does not have to choose one type exclusively. A Server Component can render content and compose selected Client Components for the interactive portions of the page. This lets teams place browser JavaScript around specific needs instead of treating the entire route as a client application.

The boundary still requires care. Moving a large component subtree behind use client can send more JavaScript to the browser, while splitting every small control into a separate boundary can make the code harder to understand. Representative pages should be measured rather than judged from the framework label alone.

Server Components are also distinct from a route's delivery strategy. A Server Component may contribute to prerendered output or participate in dynamic rendering. Describing a component as server-side does not by itself say whether the route is generated during a build, refreshed later, or produced for each request.

App Router and Pages Router

Next.js currently documents two routing systems. The App Router is the newer system and incorporates React features such as Server Components. The Pages Router is the older system and remains supported.

Area	App Router	Pages Router
Main route structure	The app directory	The pages directory
Default component model	Layouts and pages are Server Components	Uses the earlier Next.js page model
Shared UI	Nested layouts are a central convention	Commonly composed through application and page patterns
Best starting point	New work adopting the current architecture	Existing applications or dependencies built around Pages Router APIs

A migration is more than renaming folders. App Router code introduces a server-first component model and different patterns for layouts, data access, loading states, and route behavior. Teams should identify those conceptual changes before converting a mature application.

New projects should usually study App Router documentation first because it explains the framework's current model. Existing Pages Router applications should evaluate migration against actual benefits, dependencies, testing effort, and maintenance cost rather than treating continued support as a defect.

Documentation and examples may target only one router. Before copying an implementation, developers should confirm which router it uses and whether the referenced APIs apply to their project.

Rendering, caching, and revalidation

Next.js does not render every page in the same way. A route can be prepared before a visitor arrives, generated using request-specific information, cached, or refreshed according to a revalidation policy.

Route need	Likely delivery approach	Question to verify
Inputs are known ahead of time	Prerendered output	What event should cause the output to change?
Output depends on cookies, headers, or request data	Dynamic rendering	Can any part of the work still be cached safely?
Content changes on a controlled schedule	Cached output with revalidation	How stale may the response become?
No server-only feature is required	Static export may fit	Are all routes and assets compatible with export limitations?

Caching is not a single switch that can be understood independently of data access. Teams need to know which operations are cached, which routes become dynamic, and how invalidation or revalidation occurs. Those rules should be tested with realistic content changes.

This is especially important for authenticated pages, prices, inventory, dashboards, and other information with explicit freshness requirements. Serving cached output can be valuable, but only when the application's correctness rules permit it.

Performance and search visibility should not be inferred from the rendering label alone. Prerendering may reduce work at request time, and server rendering can provide meaningful initial HTML, but actual outcomes depend on page structure, assets, data latency, browser JavaScript, caching, and deployment behavior.

Static export and runtime requirements

Next.js can generate a static export when the project does not depend on server-only framework features. The resulting HTML, CSS, JavaScript, and assets can be served by infrastructure that supports ordinary static files.

Static output can still include Client Components. Static delivery describes how the built result is hosted; it does not mean that every interface must be non-interactive. Browser-side code can still provide state, events, and other client behavior.

Before choosing static export, verify that the project does not require:

• Responses generated from request-specific server data.
• Route behavior that depends on an active Next.js runtime.
• Unsupported image, routing, or server features.
• Freshness rules that cannot be met by rebuilding or another supported update process.
• Server endpoints that must execute alongside the application.

When those capabilities are required, the application needs a compatible runtime. This does not require deployment to Vercel: the official deployment guide documents self-hosting and platform adapters. Support differs by platform, so compatibility should be checked against the particular features in use.

Route Handlers and server-side endpoints

In the App Router, Route Handlers let an application define HTTP request handlers using standard request and response concepts. They are useful for endpoints that belong beside the application, including form processing, webhooks, data responses, or integration callbacks.

A Route Handler is not automatically the right home for every backend system. Teams should still decide how authentication, authorization, validation, rate controls, durable work, and error handling are managed. Long-running or independently scaled services may be better separated from the web application.

A practical review asks:

1. Does the endpoint need access to application code or shared types?
2. Does it require request-time secrets or server-only dependencies?
3. Can the target deployment execute the handler as documented?
4. What caching behavior is correct for each HTTP method and response?
5. Would a separate service provide clearer ownership or scaling?

Route Handlers make full-stack composition convenient, but convenience does not remove normal API design and security responsibilities.

Where Next.js is a practical choice

Next.js is a strong candidate for teams already comfortable with React that need application routing and server capabilities in the same codebase. It can also suit products where different routes have substantially different delivery needs.

Common fits include:

• Account areas and dashboards with both server data and interactive controls.
• Commerce or catalog experiences mixing stable content with request-dependent information.
• Documentation or marketing sites that also contain application workflows.
• Products that need HTML responses, client interaction, and server endpoints together.
• React applications whose routes benefit from separate caching and rendering policies.

The framework may be more machinery than a simple content site requires. A team publishing mostly static articles should compare its needs with tools centered on content delivery, especially if only a small portion of the site needs React interaction.

Next.js can also be a poor fit when the team cannot support its runtime requirements, does not want framework-specific rendering concepts, or would struggle to maintain clear server and client boundaries. Flexibility is valuable only when the architecture remains understandable.

Comparing Next.js with Astro and other options

Next.js and Astro are often evaluated for projects that combine content with interactive elements, but their defaults and mental models differ. The appropriate choice depends on the real routes, not a general claim that one framework is faster or better.

For a useful comparison, build the same representative page in each candidate and record:

• How much JavaScript reaches the browser before and after interaction.
• How data is loaded and how freshness is controlled.
• Whether server runtime features are required.
• How routing, layouts, forms, and error states are implemented.
• Whether the target host supports every required feature.
• How easily the team can test and explain the resulting architecture.

Astro deserves particular consideration for content-led sites where most output can remain static and interactive islands are limited. Next.js becomes more compelling when React is the central application model and server and client features need to be composed throughout the product.

Neither comparison predicts a performance score. Images, fonts, third-party scripts, component choices, data latency, and client boundaries can outweigh the framework's defaults.

Origins, governance, and community

The official governance page states that the Vercel team created Next.js in 2016. It also says that the core team at Vercel leads the project's research and development. This is a team-level origin and governance statement; it should not be replaced with an unsupported claim about an individual founder.

As documented on the governance and documentation pages available on 27 August 2026, the project's public participation paths include:

• The official GitHub repository for source code, issues, and project activity.
• GitHub Discussions for questions and community RFC discussions.
• The Next.js Discord for free community support.
• Maintained documentation for both the App Router and Pages Router.

These channels offer different kinds of help. Documentation should be the first reference for framework behavior, Discussions can surface proposals and shared questions, and Discord can support community conversation. None replaces project-specific testing or a team's own production support process.

A decision checklist

Before adopting Next.js, teams should answer these questions with a working prototype:

• Which routes are static, dynamic, cached, or revalidated?
• Which components truly require state, effects, events, or browser APIs?
• How much client JavaScript does each representative route ship?
• Which endpoints belong in Route Handlers, and which belong elsewhere?
• Can the target platform run every required Next.js feature?
• How will cache freshness, failures, logs, and deployments be managed?
• Does the team understand the differences between its chosen router and examples written for the other router?

Next.js is about applying React across a complete web application while choosing deliberately where work happens and how each route is delivered. Its documented flexibility is substantial, but it does not guarantee performance, search results, low operating cost, or architectural simplicity. Those outcomes must be established through implementation and measurement.