Chapter 01 — What is Next.js (and Why Does It Exist)?
Chapter 01 — What is Next.js (and Why Does It Exist)?
Hey everyone! 🙏 Welcome to a deep-dive series on Next.js — the most popular React framework in production today. If you already know React, you're in the right place. We're not starting from zero; we're building on top of what you know.
Before we touch any code, let's answer the most important question: what problem does Next.js actually solve? Understanding this makes every feature that follows feel obvious instead of arbitrary.
What we will cover:
- What plain React gives you (and what it doesn't)
- The problems Next.js was built to solve
- React vs Next.js — a direct comparison
- What "framework" means here vs "library"
- Who actually needs Next.js
1. What Plain React Actually Is
React is a UI library. That's it. It gives you components, state, and a way to turn data into DOM. It deliberately does NOT ship an opinion on:
- How your app is routed between pages
- Where your code runs (server vs browser)
- How your data is fetched
- How your app is bundled, optimized, or deployed
Plain React app ("Create React App" style):
=============================================
index.html ─┐
│ 1. Browser downloads ONE empty HTML shell
bundle.js ─┘ 2. Browser downloads a big JS bundle
3. JS runs, React builds the whole UI in the browser
4. THEN you see content
Problem: steps 1-3 take time. User stares at a blank
white screen until React finishes its job.
This is called Client-Side Rendering (CSR) — everything happens in the browser, after the JS has downloaded and run. It works, but it has real costs: slower first paint, worse SEO (search engines see an empty shell), and YOU have to hand-wire routing, data fetching, and build tooling yourself.
2. The Problems Next.js Was Built to Solve
THE GAP BETWEEN "REACT WORKS" AND "REACT IS PRODUCTION-READY": ================================================================= ✘ No built-in routing → you pick & configure react-router ✘ No server rendering → bad SEO, slow first paint ✘ No code-splitting strategy → you configure webpack yourself ✘ No image/font optimization → you handle it manually ✘ No API layer → you stand up a separate backend ✘ No sensible caching story → you build it yourself, badly Next.js's answer: bake ALL of this into the framework, with sane defaults, so you write React and get a fast, SEO-friendly, production app without assembling 10 libraries yourself.
Next.js was created by Vercel in 2016. Its core idea has stayed consistent: let developers write React components, but let the framework decide the smart way to route, render, and ship them.
3. React vs Next.js — Direct Comparison
| Concern | Plain React | Next.js |
|---|---|---|
| Routing | You install react-router and configure it | File-based — a folder becomes a route, automatically |
| Rendering | Only client-side (CSR) | Server rendering, static generation, streaming — your choice per route |
| Data fetching | useEffect + fetch, in the browser | Fetch directly in Server Components, before the page even reaches the browser |
| API endpoints | Need a separate backend project | Route Handlers — API endpoints live inside the same project |
| Image/Font optimization | Manual — you configure it | Built-in — next/image, next/font |
| SEO | Poor by default (empty HTML shell) | Good by default (real HTML sent from the server) |
| Deployment | Static hosting, you wire the rest | Optimized for Vercel, but deployable anywhere Node runs |
4. "Framework" vs "Library" — Why the Word Matters
LIBRARY (React): ================= YOU call it. YOU are in control of the structure. "I'll use React WHEN and HOW I want." FRAMEWORK (Next.js): ===================== IT calls you. IT decides the structure, and you fill in the blanks. "Put a file here, name it this way, and I'll wire it up." This is why file names suddenly matter in Next.js: page.js, layout.js, loading.js, error.js — these aren't suggestions, they're a contract the framework expects.
This is the biggest mental shift coming from plain React: you stop wiring things together yourself, and start following conventions the framework recognizes. Less code, but less freedom too — and that trade-off is usually worth it.
5. Who Actually Needs Next.js?
Honest answer — not every project does.
- ✅ Public-facing websites where SEO matters (marketing sites, blogs, e-commerce)
- ✅ Apps that need fast first-load (users on slow connections, mobile)
- ✅ Full-stack apps where you want frontend + backend in one codebase
- ❌ Pure internal dashboards behind a login, where SEO is irrelevant and CSR is fine
- ❌ Tiny prototypes where the extra structure just slows you down
Good engineering judgment isn't "always use Next.js" — it's knowing why you'd reach for it.
Key Points to Remember
- React is a UI library; Next.js is a framework built around React
- Plain React apps are client-rendered only — blank screen until JS loads and runs
- Next.js adds routing, rendering, data fetching, and optimization as built-in, opinionated defaults
- File names in Next.js aren't arbitrary —
page.js,layout.js, etc. are conventions the framework reads - Next.js trades some freedom for a lot of "solved for you" infrastructure
What's Next?
Now that you know why Next.js exists, next chapter we get hands-on: setting up a project and understanding the App Router folder structure from the ground up.
Keep coding, keep learning! See you in the next one!
Post a Comment