Introduction to Next.js

React changed how the web is built. Before it, building a dynamic user interface meant fighting the DOM directly, managing state manually, and producing code that was difficult to reason about at any meaningful scale. React introduced a component model that made complex UIs composable, predictable, and maintainable. It became, in a relatively short period, the dominant way to build for the web.

But React was always a library, not a framework. It solved the UI problem. It did not solve the application problem. And the gap between those two things — between a collection of components and a functioning, production-ready web application — turned out to be significant. Next.js exists to close that gap.

The Problem React Leaves Open

A React application, on its own, is a client-side experience. The browser downloads a JavaScript bundle, React executes, and the page is built in memory and rendered to the screen. For certain kinds of applications — dashboards, internal tools, highly interactive products where the user is already logged in before they see anything — this model is perfectly suited.

For everything else, it creates problems.

The first is performance. A browser cannot show the user anything until it has downloaded, parsed, and executed the JavaScript bundle. On fast connections and powerful devices, this delay is barely perceptible. On slower networks or lower-powered hardware — conditions that are far more common globally than the developer's own machine would suggest — the user waits for a blank screen while the JavaScript loads. The larger the application grows, the larger the bundle, and the longer the wait.

The second is search engine visibility. Search engine crawlers read HTML to understand what a page contains. A client-rendered React application sends the browser an almost empty HTML document — a single <div> with no content — and relies on JavaScript to populate it. Many crawlers do not execute JavaScript, or execute it unreliably. A site built this way can be functionally invisible to search engines, which is an unacceptable tradeoff for any product that depends on being discoverable.

The third is architecture. The moment a React application needs data — user records, product listings, content from a database — it needs a backend to supply that data. In a pure client-side setup, that means a separate server, a separate deployment, a separate codebase, and all the coordination overhead that comes with maintaining two distinct systems. For many applications, this separation is entirely unnecessary complexity.

Next.js addresses all three. It introduces server-side rendering that produces real HTML before the browser receives anything. It provides a model for co-locating server logic and frontend components in the same codebase. And it ships with the build tooling, performance optimisations, and conventions that turn a React project into something ready for production.

What Next.js Is

Next.js is an open-source, full-stack web framework built on top of React and Node.js. It is maintained by Vercel, the cloud platform company, and has been under active development since its initial release in 2016. The framework is used in production by companies ranging from small startups to large enterprises — among them Notion, Twitch, Hulu, and The Washington Post.

At its core, Next.js is a set of conventions and capabilities layered on top of what developers already know. React handles the component model. Node.js provides the server runtime. Next.js coordinates between the two — routing requests, orchestrating rendering, managing data fetching, and handling the build and deployment process — so that developers can focus on writing application code rather than infrastructure.

The framework's defining characteristic is that it makes decisions. React is famously unopinionated: it provides tools and leaves the choices to the developer. Next.js makes specific, well-considered choices about how routing works, how rendering is structured, and how the frontend and backend are connected. Those choices are the framework. Understanding them is what it means to understand Next.js.

A Brief History

Next.js was created by Guillermo Rauch and released by Vercel in October 2016. The initial release was built around a single insight: server-side rendering with React, which was theoretically possible, was practically painful to set up. Next.js made it trivial.

The framework grew steadily as React's dominance in the frontend ecosystem solidified. Early versions introduced features that became foundational conventions: file-system-based routing, where a file's location in the project determines its URL; automatic code splitting, where each page only loads the JavaScript it actually needs; and static site generation, where pages are pre-built at deploy time rather than rendered on each request.

The most significant architectural shift came in 2022 with the introduction of the App Router — a new approach to building Next.js applications, built around React Server Components. The App Router changed how routing, layouts, and data fetching work at a fundamental level. It represented a more ambitious vision of what a React framework could be: not just a layer on top of React's existing model, but a collaboration with React itself on what the future of server-rendered applications should look like.

The App Router is now the recommended and default architecture. The older system, known as the Pages Router, remains supported for existing applications but is no longer the direction of active development. This research series covers the App Router exclusively.

The Stack Next.js Brings Together

Next.js does not introduce a new language or a new paradigm. It takes technologies that developers already know — or are in the process of learning — and integrates them into a coherent whole.

React provides the component model. Every UI element in a Next.js application is a React component. The knowledge of JSX, props, state, and component composition that comes from learning React applies directly and completely.

Node.js provides the server runtime. When a Next.js application is deployed and handling real requests, it is Node.js executing the server-side code — the same event loop, the same module system, the same async patterns. The rendering that happens on the server, the API endpoints that handle data, the middleware that processes requests — all of it runs on Node.js.

TypeScript is a first-class citizen in Next.js. The framework is written in TypeScript, its documentation examples default to TypeScript, and a new project scaffolded with the create-next-app CLI configures TypeScript automatically. The type safety research from earlier in this series applies directly to how Next.js code is written day to day.

What Next.js adds on top of these is its own contribution: the routing system, the rendering orchestration, the build pipeline, and the conventions that make the whole thing work as a unified application rather than a collection of individual pieces.

What the Framework Provides

A list of features risks flattening what is actually a coherent architecture into a set of bullet points. But it is useful to name what Next.js concretely provides before exploring each piece in depth across the remaining topics in this series.

File-system routing. Routes in a Next.js application are determined by the file and folder structure of the app directory. A folder named blog with a page.tsx file inside becomes a /blog route. A folder named [id] becomes a dynamic route that captures whatever value appears in the URL at that position. There is no routing configuration file and no route registration step — the file system is the router.

Server Components. React components run on the server, not in the browser. They can fetch data directly, access server-only resources, and produce fully rendered HTML that reaches the client immediately. Server Components are one of the most important ideas in modern React, and Next.js is where they are most mature and most usable.

Client Components. Components that run in the browser, maintaining the interactive React model that has always existed — state, event handlers, browser APIs. In the Next.js App Router, components are Server Components by default. Client Components are opted into explicitly with the 'use client' directive.

Route Handlers. API endpoints defined inside the Next.js project, written as functions that receive a request and return a response. Instead of a separate backend service, the application's API can live in the same codebase as its frontend.

Multiple rendering strategies. Pages can be pre-rendered at build time, server-rendered on each request, or rendered in the browser. Next.js supports all three and allows the right strategy to be chosen per page or per component.

Built-in performance optimisations. Image loading, font delivery, and script handling are all managed by Next.js with production performance as the default. Code is automatically split per route so users only download what they need.

Next.js and Vercel

The relationship between Next.js and Vercel is worth understanding clearly. Next.js is open source, licensed under the MIT licence, and runs on any platform capable of running Node.js — a standalone server, AWS, Railway, Render, a Docker container, or any other hosting provider. There is no licence requirement, no vendor lock-in, and no feature that requires Vercel to function.

Vercel built Next.js because a powerful and popular React framework drives adoption of the Vercel deployment platform. This is a transparent business arrangement and a healthy one — it means Vercel has a strong incentive to keep Next.js excellent and well-maintained. The framework is actively developed, frequently updated, and backed by a team whose commercial interests are aligned with making it as good as possible.

Certain features — Edge Middleware, certain caching behaviours, advanced image optimisation — are most seamlessly integrated with Vercel's own infrastructure. On other hosting providers, the same features work but may require additional configuration. This is worth knowing, but it is a practical consideration rather than a fundamental constraint.

What This Series Covers

The topics in this Next.js series are structured to build understanding progressively. Project structure and file conventions come first, establishing the physical layout of a Next.js application. Routing follows — both static and dynamic. Server Components and Client Components are addressed as a dedicated topic because the distinction between what runs on the server and what runs in the browser is central to everything else. Data fetching, rendering strategies, metadata, and deployment complete the picture.

By the end, the framework should feel not like a collection of features to memorise but like a coherent system with a clear logic — one where each piece is present for a reason, and where that reason connects back to the problems that motivated Next.js's existence in the first place.

The Next.js research series on this platform draws from the official Next.js documentation at nextjs.org/docs, maintained by Vercel. Documentation content is licensed under the Creative Commons Attribution 4.0 International License.