What Is Next.js? Full-Stack React Explained

Next.js is the most widely used React framework today. If you have read through plain React and wondered how real production apps handle routing, data fetching, and server rendering, the answer is almost always Next.js. This post explains what it is, why it exists on top of React, and what changes the moment you adopt it.

What Next.js is

Next.js is an open-source full-stack framework built on top of React. It is maintained by Vercel and a large community, and the version this series teaches is Next.js 15 with the App Router and React 19.

Plain React renders UI. That is the entire job. Routing, data fetching, server rendering, bundling, caching, and deployment are all problems you solve yourself by stitching together libraries. Next.js bundles all of that into a single coherent framework so you can focus on the actual product.

The smallest possible Next.js page looks like this:

// app/page.tsx
export default function Home() {
  return <h1>Hello from Next.js</h1>;
}

That one file is a complete route. No router setup, no manual mount call, no separate HTML file. Next.js takes the file, treats its path as a URL, server-renders it on request, hydrates it in the browser, and serves it.

Framework vs library

React calls itself a library because it focuses on one thing: turning state into UI. Next.js calls itself a framework because it ships opinionated answers for:

• Routing — file-system based, no React Router needed
• Rendering — server-side, static, and client-side, all from the same code
• Data fetching — fetch() with built-in caching and revalidation
• API endpoints — route handlers that run on the server
• Bundling — Turbopack out of the box, no Webpack or Vite config
• Image, font, and script optimization — built-in components
• Deployment — first-class support on Vercel, with adapters for other hosts

You can build a production app without bolting on react-router-dom, an Express server, a separate API project, or a custom Webpack config. The trade-off is that you adopt Next’s opinions. For most production work, that trade is worth it.

The App Router

Next.js currently ships with two routing systems: the older Pages Router (in pages/) and the newer App Router (in app/). Every new project should use the App Router. It is the default since Next.js 13.4, the focus of the official docs, and the only place where React Server Components and the modern caching model live.

The App Router uses the file system to define routes:

app/
├── layout.tsx          // root layout, wraps everything
├── page.tsx            // /
├── about/
│   └── page.tsx        // /about
├── blog/
│   ├── page.tsx        // /blog
│   └── [slug]/
│       └── page.tsx    // /blog/:slug
└── dashboard/
    ├── layout.tsx      // shared layout for /dashboard/*
    └── page.tsx        // /dashboard

Three conventions do most of the work:

• page.tsx defines a URL. The folder path is the URL path.
• layout.tsx wraps every page below it. Layouts nest.
• [slug] is a dynamic segment that becomes a parameter.

We go deeper in The Next.js App Router: Pages, Layouts, and Routing.

React Server Components

The other big idea is React Server Components (RSC). In the App Router, every component is a Server Component by default. That means:

• The component runs on the server, not in the browser
• It can be async and await data directly inside the function body
• It ships zero JavaScript for itself to the client
• It cannot use useState, useEffect, or browser APIs

If you need interactivity, you opt a component into the client with the "use client" directive at the top of the file. That component and its children become a normal interactive React tree that runs in the browser.

// app/page.tsx — server component
async function Home() {
  const posts = await fetch('https://api.example.com/posts').then((r) =>
    r.json()
  );

  return (
    <main>
      {posts.map((p: { id: string; title: string }) => (
        <article key={p.id}>{p.title}</article>
      ))}
    </main>
  );
}

export default Home;

You just fetched data inside a component, with await, and no useEffect. That is the headline feature. We dedicate a full post to it in Next.js Server Components Explained.

File-based routing in practice

Coming from React Router, file-based routing feels strange for about a day, then obvious. Instead of:

// React Router
<Routes>
  <Route path="/" element={<Home />} />
  <Route path="/blog/:slug" element={<Post />} />
</Routes>

You write:

app/
├── page.tsx               // Home
└── blog/
    └── [slug]/
        └── page.tsx       // Post

The router is the file tree. There is no central route configuration to keep in sync. New routes appear by creating folders.

Where Next.js fits

A short, honest map of the surrounding tools.

vs. a Vite React SPA

Plain React on Vite is a single-page app. The server sends an empty HTML shell, the browser downloads a JavaScript bundle, and React renders the page on the client. It is the simplest model and the cheapest to host, but every page starts from scratch in the browser.

Next.js renders the first page on the server and streams HTML to the browser, then hydrates it. The first paint is faster, the SEO is better, and the data lives next to the components that use it. The cost is more concepts and a slightly heavier deploy target.

For a learning project or an internal tool, a Vite SPA is fine. For a public product, Next.js is the default.

vs. Astro

Astro is a content-first framework that ships zero JavaScript by default and lets you sprinkle React, Vue, or Svelte components on top. It is the best choice for blogs, marketing sites, and documentation — which is why CodeLoom itself uses Astro.

Next.js is the better choice when the whole app is interactive: dashboards, social feeds, e-commerce flows, anything with auth and per-user data.

vs. Remix / React Router v7

Remix and Next.js solve overlapping problems. Remix focuses on web fundamentals, nested routing with loaders and actions, and progressive enhancement. Since merging with React Router v7, that approach has become the React Router story too.

Both are excellent. Next.js has the larger ecosystem, more job postings, and tighter integration with Vercel. Remix has a cleaner mental model for forms and mutations. You will not go wrong with either.

vs. classic Express + React

A few years ago the standard stack was an Express API on one server and a React SPA on another. Next.js collapses both into one project — Server Components handle data on the server, route handlers replace small Express endpoints, and you ship one deploy artifact. You can still call a separate backend; Next.js just removes the need to build the glue.

The Vercel relationship

Next.js is built by Vercel, the company that also runs a hosting platform. This makes some people nervous. A few honest notes.

• Next.js is MIT licensed and runs anywhere Node.js runs. You can deploy it to AWS, Cloudflare, Netlify, Railway, your own VPS, or a Docker container.
• Vercel funds most of the core team. The framework’s roadmap reflects what Vercel can build a business on — fast cold starts, edge rendering, image optimization. Most of those features benefit everyone.
• Some features (notably ISR cache persistence and certain image optimizations) are easiest to run on Vercel, but every one of them has a self-host story documented in the official docs.

If you are weighing Next.js purely on the framework, treat the Vercel connection the way you would treat React being from Meta. It funds the project; it does not lock you in.

What Next.js gives you out of the box

A practical inventory of what arrives in a fresh create-next-app project.

• App Router with nested layouts and Server Components
• Turbopack as the dev bundler (Webpack still available for some plugins)
• TypeScript by default
• ESLint configured
• Tailwind CSS as an optional default
• next/image for automatic image optimization
• next/font for self-hosted fonts with no layout shift
• next/link for client-side navigation
• Route handlers in app/**/route.ts for API endpoints
• Middleware for auth, redirects, and rewrites at the edge
• Built-in caching with fetch(), revalidate, and tags

That is roughly the union of react-router, axios, a custom Express server, a Webpack config, an image CDN, and a font loader — all wired together.

What Next.js does not give you

Worth being honest about. Next.js does not ship:

• A database or ORM (use Prisma, Drizzle, or your hosted database SDK)
• An auth library (Auth.js, Clerk, Supabase Auth, or build your own)
• A UI component library (shadcn/ui, Mantine, or whatever you prefer)
• A form library (React Hook Form is a popular choice)
• A global state library (Zustand and Jotai are common; often you do not need one)

These are intentional. Picking your database and your auth provider is your decision, not the framework’s.

What you need to get started

To follow the rest of this series you need:

1. Node.js 20 or newer — Node 22 is the current LTS
2. A code editor — VS Code is the default
3. A terminal you are comfortable with
4. Working knowledge of React — props, state, components

You do not need TypeScript experience to read this series, though every code block uses it. The TypeScript is light and the patterns are exactly the same in JavaScript.

Recap

You now know:

• Next.js is a full-stack React framework maintained by Vercel
• It bundles routing, rendering, data fetching, and deployment into one project
• The App Router uses the file system to define routes and supports nested layouts
• React Server Components are the default — components run on the server and ship no JS
• Next.js sits between a Vite SPA (simpler) and a custom Express + React stack (heavier)
• It is MIT licensed and self-hostable; Vercel funds the project but does not own it

Next steps

The next post walks through installing Next.js with create-next-app, touring the generated project, and running the dev server — in about ten minutes.

→ Next: Install Next.js and Build Your First App

Questions or feedback? Email codeloomdevv@gmail.com.