The convention list, in one place
Every problem React leaves open, Next.js answers with a convention. Memorize the table once and you stop rediscovering it later:
| Problem | Convention |
|---|---|
| Routing | File-system: a folder with page.tsx = a route |
| Layouts | layout.tsx per segment, persists across navigation |
| Loading state | loading.tsx, wired into Suspense automatically |
| Errors | error.tsx per segment, global-error.tsx at root |
| API endpoints | route.ts handlers (GET/POST/…) |
| Server data | async Server Components, fetch directly |
| Mutations | Server Actions ('use server') |
| Bundling | Turbopack (Rust) — default since v16 |
| Images / fonts / scripts | next/image, next/font, next/script |
| Production server | next start — Node anywhere, or self-host edge |
The shape of a starter
The CLI sets the defaults you'll inherit for everything else: TypeScript on, ESLint on, App Router on, Turbopack on, Tailwind optional, src/ optional, import alias @/*.
Why it's worth learning the table
Most Next.js confusion comes from skipping the convention list and reaching for a third-party package that already exists in the box. Look at the table first; if it's there, prefer the built-in.
Before adding a package, name the responsibility and check whether Next.js already owns it through a file convention or built-in API. Prefer the built-in path when it satisfies the requirement and shares the same routing, caching, and server-component assumptions.
Built in does not mean universally sufficient. A specialized requirement may justify another library, but that choice should identify the capability gained and the new upgrade, failure, and deployment contracts introduced. Choose one feature and implement or diagram both the built-in and external-package paths. Record where routing, loading, errors, caching, and deployment are configured, and explain why the extra contract is worth keeping.