meta-framework Introduced in L3

Next.js

The React meta-framework. Pages, routing, server-rendering, API routes, image optimization — the things you'd otherwise wire up yourself, bundled in.

Mindmap

hover · click to navigate
this tech depends on / used by alternative Shipyard anchor
What it is

The plain-English version

Next.js is a meta-framework built on top of React, made by Vercel. It adds opinionated solutions for routing, server rendering (SSR), static generation (SSG), API routes, image optimization, and a lot of build tooling. You pick Next.js when you want React but don't want to assemble the rest of the toolkit yourself.

Why it exists

The problem it solves

Plain React leaves a lot of decisions to you: routing, data fetching, build tooling, server rendering. Next.js takes opinionated stances on all of them. This is why it's the default choice for many production teams — and the default that AI agents reach for when you say "build me a web app."

What it competes with

Alternatives

AlternativeTypeWhen it wins
ReactlibraryThe dominant JavaScript library for building component-based user interfaces. The thing your AI agent reaches for unless you tell it not to.
SvelteframeworkA frontend framework that compiles components down to plain JavaScript at build time. Smaller bundles, less runtime weight, beloved by developers.
Where it shows up in Shipyard

Deep links

Vocabulary

The words you'll hear

App Router
Modern routing (Next 13+). Folder-based, with React Server Components.
Pages Router
Original routing, still widely used. Files in pages/ become routes.
Server Components (RSC)
Components that render on the server only. No client JS shipped for them.
Route handlers
API endpoints (route.ts in App Router; pages/api/* in Pages).
ISR
Incremental Static Regeneration. Static pages that periodically rebuild themselves.
Edge runtime
Lightweight runtime for code at CDN edge. Faster cold start, narrower API.
Prompting

Bad vs. good prompt for Next.js

✕ Bad prompt
Set up auth in next.js
✓ Good prompt
Add Auth.js (NextAuth v5) to our existing Next.js 14 App Router project with Google OAuth. The session should be JWT, not database. Protect /dashboard and any /api routes under /api/protected. Store the GOOGLE_CLIENT_ID/SECRET in .env.local. Show me the diff and explain the middleware.

Why it works: Specifies version (Next 14, Auth.js v5), strategy choice (JWT not DB), exact paths to protect, env var convention, and asks for explanation. Avoids mismatched docs from the App/Pages transition.

Pitfalls

What bites real teams

⚠ Mixing App Router and Pages Router carelessly

They coexist but have different mental models. Mixing them in one project is fine; mixing them in one feature is confusing. Pick a side per feature.

⚠ Server Components confusion

By default, components in App Router are server-side. useState, onClick require "use client" at the top. The error message is helpful; read it.

⚠ Caching surprises

Next has aggressive caching defaults that can stale data unexpectedly. Read the caching docs once carefully, then opt-in or opt-out deliberately.

References

Official docs only