next.js: a full-stack React framework

What it is

Next.js is a full-stack React framework that gives you routing, data-fetching, rendering, and build tooling in one opinionated package. Instead of wiring Webpack/Vite, routers, API layers and deployment glue yourself, you get a single abstraction that can do server-side rendering, static generation, incremental static regeneration, and client-side hydration from the same codebase.

It leans on modern React features (Server Components, Suspense, Server Actions) and Rust-based tooling under the hood to keep builds fast while still supporting very large apps used by big companies in production.

What’s new

As of late 2025, the headline is Next.js 16 and the tail end of the 15.x line. Next 16 tightens the Turbopack story: configs move to a new turbopack block in next.config.js, and the framework nudges you away from older build/middleware conventions. The next lint command is deprecated in favour of using the ESLint CLI directly, and the older middleware pattern gives way to a proxy-based approach, with codemods to migrate existing apps. A number of previously experimental APIs lose their unstable_ prefixes as they stabilise.

On the 15.x side, the most recent notable release, Next.js 15.5, brings Turbopack production builds (next build –turbopack) into beta, stabilises the Node.js runtime for middleware, and adds stronger TypeScript support around routes (typed routes, export validation, helpers). It also starts surfacing deprecation warnings in preparation for the 16 upgrade path and phases out next lint.

Earlier 15.x releases introduced React 19 support, improvements to hydration error debugging, new caching semantics (uncached by default for fetch, GET Route Handlers and the client router cache), and deeper Turbopack integration for both dev and build workflows.

What else is similar to it

Next.js sits in the “full-stack React (or frontend) framework” space alongside a few close neighbours. Remix offers nested routing and a “web fundamentals first” approach with strong emphasis on HTTP semantics and progressive enhancement.

Gatsby historically focused on content sites and static generation with a strong plugin ecosystem, though its role has shifted more towards maintaining existing sites than leading the cutting edge. RedwoodJS targets SaaS and startups with an opinionated full-stack story around React, GraphQL and Prisma.

Outside the React world, Nuxt (Vue), SvelteKit (Svelte) and Astro (content-first, multi-framework) solve similar “build full experiences, not just components” problems with different trade-offs around SSR, static output, and how much of the stack they own.

Why it’s different

Next.js stands out because of how much of the stack it unifies while still feeling like React. The App Router plus React Server Components gives you streaming, granular data-fetching and partial rendering without manually juggling APIs and client caches. Server Actions and Route Handlers let you colocate server logic with UI instead of scattering it across separate services or ad-hoc endpoints.

Turbopack and the surrounding Rust-based tooling aim to preserve performance even as projects grow large, and Vercel’s hosting platform doubles down on this integration with zero-config deployment paths for most apps.

Compared to more minimal meta-frameworks or bare bundlers, Next.js is intentionally “batteries included”: routing, rendering modes, asset optimisation, edge/middleware and deployment alignment are all designed to work together, which is why it’s become the default choice for many React teams building serious products.

How to get started

• Visit nextjs.org and skim the “Learn” and “Docs” sections to understand the current App Router-first model and rendering options.
• Scaffold a project with the official starter: npx create-next-app@latest, choosing the App Router and TypeScript if you’re starting fresh.
• Run npm run dev (or your package-manager equivalent) to start the dev server, then inspect the generated folder structure (app/, app/api/, public/, next.config.js) to see how routing and assets are wired.
• Add a simple server component page that fetches data with fetch on the server and a client component that interacts with state, so you feel the server/client split in practice.
• Experiment with one advanced feature at a time, e.g. Server Actions for mutations, Route Handlers for APIs, or a small Turbopack trial next dev --turbopack / next build --turbopack on a branch, so your mental model grows with the framework rather than all at once.