Next.js Introduction

React gives you components and nothing else. The moment you need routing, server rendering, or a production build pipeline, you are on your own — bolting together a router, a bundler, and a data-fetching strategy. Next.js exists so you do not have to. It is a React framework that provides all of that with defaults that just work.

This introduction explains what Next.js actually adds on top of React, how its file-based routing turns folders into URLs, the rendering modes that make it fast and SEO-friendly, and how you build your first page. If you already know React components, you know most of what you need.

React is a library; Next.js is a framework

The distinction is worth getting right because interviewers ask it constantly. React is a library for building user interfaces — it renders components and manages state, and stops there. Next.js is a framework that uses React and answers the questions React leaves open:

• How do URLs map to pages? → file-based routing
• Where does rendering happen — browser or server? → server, static, or client rendering
• How do I fetch data efficiently? → server components and built-in fetching
• How do I ship an optimized production build? → automatic code splitting, image and font optimization

If plain React and its component model are still new, start with what React is and the React learning hub — Next.js will make far more sense once components, props, and hooks feel natural.

Pro tip: A clean one-liner for interviews: "React builds the UI; Next.js is the framework around React that handles routing, rendering, and optimization." That single sentence answers the most common Next.js opening question.

File-based routing: folders become URLs

In a plain React app you install a router and describe every route in code — the approach covered in the React Router tutorial. Next.js takes a different path: your folder structure is your routing. Inside the app directory, each folder with a page file becomes a route.

app/
  page.jsx          →  /
  about/
    page.jsx        →  /about
  blog/
    page.jsx        →  /blog
    [slug]/
      page.jsx      →  /blog/:slug  (dynamic route)

No route config to write, no <Route> elements to register. Create a folder, add a page.jsx, and the URL exists. The [slug] folder in square brackets is a dynamic route — it matches any value in that position, so /blog/react-basics and /blog/nextjs-intro both hit the same page file, which reads the slug to load the right content.

Special filenames add structure: layout.jsx wraps every page beneath it (perfect for a shared navbar), and loading.jsx shows instantly while a page loads its data.

Your first page

A Next.js page is just a React component that the file exports as default. Here is the home page:

// app/page.jsx
export default function HomePage() {
  return (
    <main>
      <h1>Welcome to my Next.js site</h1>
      <p>This page is rendered on the server and sent as ready HTML.</p>
    </main>
  );
}

That is a complete, routable page at /. You did not configure a route, set up a bundler, or write server code — Next.js handled all of it. To add an /about page you create app/about/page.jsx and export a component from it. Navigation between pages uses a Link component that prefetches the destination for near-instant transitions:

import Link from "next/link";

export default function Nav() {
  return (
    <nav>
      <Link href="/">Home</Link>
      <Link href="/about">About</Link>
    </nav>
  );
}

Link renders a real anchor but intercepts the click to swap pages without a full reload, and it prefetches the target page's code in the background — one reason Next.js apps feel fast.

Rendering modes: the real reason to use Next.js

The feature that pushes teams to Next.js is where and when pages render. Plain React renders entirely in the browser: the server sends a nearly empty HTML shell, then JavaScript downloads and builds the page. That is fine for a logged-in dashboard but poor for SEO and slow on a first visit.

Next.js offers three strategies, and you can mix them per page:

• Server-Side Rendering (SSR): the page is rendered to HTML on the server for each request. Great for content that changes often and must be indexable.
• Static Site Generation (SSG): the page is rendered once at build time and served as a static file. Fastest possible delivery, ideal for blogs and marketing pages.
• Client-Side Rendering (CSR): the classic React approach, for highly interactive pieces that do not need SEO.

Because the HTML arrives already filled with content, search engines and social-media previews see your real text immediately — the core reason Next.js is considered SEO-friendly.

Common mistake: Assuming Next.js means "no more client-side React". Interactivity still runs in the browser. Next.js just lets you choose server rendering for the parts that benefit, while keeping React's interactivity where you need it.

Server Components and Client Components

Modern Next.js builds on React Server Components. By default, components in the app directory run on the server: they render to HTML, can fetch data directly, and ship zero JavaScript for themselves — lighter pages, faster loads.

When a component needs interactivity — state, event handlers, effects — you opt it into the browser by adding "use client" at the top:

"use client";
import { useState } from "react";

export default function LikeButton() {
  const [likes, setLikes] = useState(0);
  return <button onClick={() => setLikes(likes + 1)}>Likes: {likes}</button>;
}

The rule of thumb: keep components on the server by default, and reach for "use client" only where you actually use state or events. This split keeps most of your app lightweight while preserving full interactivity where it matters — and it connects directly to the performance techniques you use to keep client bundles small.

Data fetching, the Next.js way

Because server components run on the server, they can fetch data inside the component with plain async/await — no useEffect, no loading-state juggling:

// app/users/page.jsx — a server component
export default async function UsersPage() {
  const res = await fetch("https://api.example.com/users");
  const users = await res.json();

  return (
    <ul>
      {users.map((u) => <li key={u.id}>{u.name}</li>)}
    </ul>
  );
}

The data is fetched on the server, the HTML arrives complete, and no fetching JavaScript is sent to the browser. Compared with the client-side useEffect fetch pattern, this is simpler to write and better for SEO.

What else Next.js gives you for free

Routing and rendering get the headlines, but a lot of Next.js's value is in the smaller things it optimizes automatically so you never think about them:

• Image optimization — the next/image component resizes, compresses, and lazily loads images and serves modern formats, which is one of the biggest wins for page speed.
• Automatic code splitting — each route ships only the JavaScript it needs, so visiting one page never downloads the whole app.
• Font optimization — next/font loads web fonts without the layout shift that hurts perceived performance and Core Web Vitals.
• API routes — you can add backend endpoints inside the same project by creating route handlers, so a small app can serve its own API without a separate server.
• Built-in metadata — you set page titles and descriptions per route with a simple export, which matters directly for SEO.

None of these require configuration. You get them by using the framework, which is the whole appeal: sensible defaults that would each take real effort to wire up in a plain React app.

Interview note: If asked "why would a team choose Next.js over Create React App or a Vite SPA?", name three concrete things: server rendering for SEO, file-based routing with no config, and the automatic performance optimizations above. Concrete features beat the vague answer "it's better".

Where to go from here

Next.js is the framework behind a large share of production React apps, so knowing it opens real doors. But the order matters: get comfortable with React components, props, state, and hooks first, then layer Next.js on top for routing and rendering. If you have not built a plain React app yet, do that with the Vite setup guide before diving in here.

At CodeBegun's Java Full Stack with AI program in Hyderabad, students build a Next.js front end that talks to a Spring Boot backend, so file-based routing, server rendering, and data fetching become part of a full application rather than isolated demos. Start with one page, add a second, wire up a Link between them — and you have already used the core of Next.js.