What is Next.js?

React gives you components, state, and a way to describe UI — but it doesn't tell you how to route between pages, where data fetching should happen, or how your app gets bundled and served. Every React project ends up answering those questions somehow, usually by wiring together a router, a bundler, and a data-fetching strategy by hand. Next.js is a meta-framework: it takes React and adds the missing pieces — routing, rendering, bundling, and optimization — as built-in conventions instead of decisions you make from scratch.

The rendering problem React doesn't solve

A plain React app (built with something like Vite) ships an empty HTML page and a JavaScript bundle. The browser downloads the JS, runs it, and only then does the user see anything. That's client-side rendering (CSR) — simple, but it means slower first paints and a blank page for search engine crawlers that don't execute JavaScript.

Next.js instead renders on the server by default. It runs your components on a server (or at build time), produces real HTML, and sends that to the browser immediately. The page appears fast, and crawlers see actual content. React then "hydrates" that HTML in the browser, attaching event listeners so it becomes interactive.

// This component runs on the server. No useEffect, no loading spinner —
// the HTML Next.js sends already contains the rendered list.
export default async function Page() {
  const res = await fetch("https://api.example.com/posts");
  const posts = await res.json();

  return (
    <ul>
      {posts.map((post: { id: string; title: string }) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

SSR and SSG, in plain terms

Next.js supports rendering the same component tree in different ways depending on what the page needs:

• Server-Side Rendering (SSR) — the page is rendered fresh on every request. Good for content that changes per-user or per-request, like a dashboard.
• Static Site Generation (SSG) — the page is rendered once, at build time, and reused for every visitor until you explicitly regenerate it. Good for content that's the same for everyone, like a marketing page or a blog post.

You don't pick one globally — different routes in the same app can use different strategies, and Next.js figures out a sensible default based on what APIs your code touches (a database call vs. reading cookies, for example).

The App Router

Next.js has gone through two generations of routing conventions. The older one, the Pages Router, is still supported but is no longer where new features land. This course focuses entirely on the App Router — the app/ directory convention that's been the primary way to build Next.js apps since Next.js 13, and the one you should reach for in any new project.

Why this matters in practice

Choosing Next.js over plain React isn't just about speed — it changes where your code runs. Data fetching, secrets, and database calls can live on the server, never shipped to the browser. The rest of this course builds up from a single page to full routing, data fetching, mutations, and deployment, all within that server-first model.