What Is Next.js?
Next.js is a React framework for building web applications — combining server-side rendering, static site generation, API routes, and edge middleware in one production-ready package.
Next.js is a React framework for building production web applications. It adds file-based routing, multiple rendering strategies (static, server-side, and streaming), an API layer, and image optimization on top of React, so a single codebase serves both the frontend and its backend endpoints.
In plain terms: React gives you the UI library; Next.js gives you the structure, the server, and the build pipeline around it. It is the most widely used way to ship React to production.
How it works
Next.js decides where and when each page renders. A route can be turned into static HTML at build time, rendered fresh on every request, or streamed from the server as React Server Components. You pick the mode per route, and the framework wires up the caching, routing, and data fetching to match.
The four rendering modes:
| Mode | When it renders | Best for |
|---|---|---|
| Static Site Generation (SSG) | At build time, served from a CDN | Marketing pages, blogs, docs |
| Server-Side Rendering (SSR) | On every request | Dashboards, personalized or auth-gated pages |
| Incremental Static Regeneration (ISR) | Build time, then re-generated on a schedule | Content that changes occasionally (pricing, listings) |
| Server Components (App Router) | On the server, sends HTML, ships less client JS | Data-heavy pages that fetch close to the database |
App Router vs Pages Router
Next.js 13 introduced the App Router, built on React Server Components, where components run on the server by default and send HTML instead of a JavaScript bundle. The older Pages Router is still stable and supported, but new projects generally start on the App Router. The two can coexist in one app during a migration.
When to use Next.js — and when not to
Reach for Next.js when:
- You want server-rendered HTML for SEO without running a separate backend.
- You need API routes and a frontend in one deployment.
- The product is content-heavy or has pages that benefit from static generation.
- You are deploying to a platform like Vercel and want push-to-deploy with no server config.
Look elsewhere when:
- You are building a purely client-side app (an internal tool behind a login, a heavy interactive canvas) where SEO and server rendering add no value — plain React with Vite is lighter.
- You need a long-running stateful backend (websockets at scale, background job queues). Next.js API routes are request/response handlers, not a full application server. Pair it with a dedicated backend instead.
- Your team has no React experience — the framework assumes React fluency.
Common mistakes
- Putting
"use client"at the top of everything. That opts whole trees out of server rendering and ships the JavaScript you were trying to avoid. Keep components on the server by default; mark only the interactive leaves as client components. - Treating API routes as a heavy backend. They are serverless functions with cold starts and execution limits — fine for form handlers and light data access, wrong for long-running work.
- Fetching data in client components when a server component could do it. Server-side fetching keeps secrets off the client and avoids a render-then-fetch waterfall.
- Forgetting that ISR revalidation is eventual. A regenerated page can serve stale content until the next revalidation window.
A concrete example
A booking SaaS uses Next.js to render its public listing pages statically (fast, indexable), renders the logged-in dashboard server-side per request (always current, behind auth), and exposes a few API routes for webhooks and form submissions. The same repo deploys as one unit. This is the shape behind real React/Next-style projects I've shipped — for example Callidus, a clinic SaaS on React + Firebase, and Pizzeria Bestek on React + Supabase.
Why it matters for SEO
Server-rendered HTML is visible to crawlers and AI answer engines on first load, with no JavaScript execution required. A client-only React app makes those crawlers run JS before any content appears, which is slower and less reliable to index. Next.js removes that barrier for most page types — one of the main reasons content sites and SaaS marketing pages choose it.
Key takeaways
- Next.js = React + routing + a server + a build pipeline, in one framework.
- You choose rendering per route: static, server, incremental, or streamed server components.
- App Router is the current direction; Pages Router still works.
- Best fit for SEO-sensitive, content-heavy, or full-stack React products; overkill for purely client-side internal tools.
Thinking through whether Next.js fits a specific build, or want it built — contact me for a quote. I ship full-stack React and Next.js work, typically without agency timelines and overhead.