Over the past days of my 100 Days of Code challenge, I learned how to build UI components with React, manage state, and handle user interactions on the frontend. On the backend side, I worked with Node.js and Express.js to build APIs, connected them to databases, and understood how data flows between the client and the server. But as I kept building, one thing became obvious — maintaining a separate frontend and backend project, manually setting up routing with React Router, and figuring out how to make pages SEO-friendly was adding a lot of overhead to every project.
This is where Next.js changes the game.
What is Next.js
Next.js is a React framework that helps you build:
- Faster apps
- SEO-friendly apps
- Full-stack applications
Key features Next.js adds to React:
| Feature | What it means |
|---|---|
| File-based routing | Your folder structure is your routing |
| Server-Side Rendering (SSR) | Pages are rendered on the server per request |
| Static Site Generation (SSG) | Pages are pre-built at deploy time |
| API Routes | Write backend endpoints inside your frontend project |
Why Next.js Exists
Plain React is a UI library. It's great at building interfaces, but it doesn't tell you:
- How to structure your project
- How to handle routing
- How to render things on the server
- How to write backend logic alongside your frontend
That's where frameworks exist — and Next.js fills all those gaps for React.
Next.js solves these problems by giving you a full-stack framework on top of React.
React SPA vs Next.js
React SPA vs Next.js: What's the Real Difference?
A plain React app is a Single Page Application (SPA). The browser downloads one HTML file, then JavaScript takes over and renders everything client-side.
Next.js changes this model:
| React SPA | Next.js | |
|---|---|---|
| Rendering | Client-side only | Server + Client |
| SEO | Poor (JS-heavy) | Better (HTML sent from server) |
| Routing | Manual (React Router) | Built-in (file-based) |
| Backend | Separate project | API routes built-in |
| Performance | Depends on bundle size | Optimized by default |
This is a mindset shift, not just a syntax change.
Pages Router vs App Router
Next.js has two routing systems. You'll likely encounter both, but the App Router is the modern, recommended approach.
Pages Router (pages/) |
App Router (app/) |
|
|---|---|---|
| Introduced | Original Next.js | Next.js 13+ |
| Status | Still supported | Recommended going forward |
| Default component type | Client Components | Server Components |
👉 Use App Router for any new project. The Pages Router still works and is still widely used in older codebases, so it's worth knowing it exists.
Project Structure
When you create a new Next.js app, here's what the key files and folders mean:
my-app/
├── app/
│ ├── layout.js ← Wraps all pages (like a shell/template)
│ ├── page.js ← The "/" homepage route
│ └── globals.css ← Global styles
├── public/ ← Static assets (images, fonts)
├── next.config.js ← Next.js configuration
└── package.json
The app/ folder is the App Router. Everything inside it is a route, a layout, or a component.
File-Based Routing: One of the Biggest Shifts
This is one of the most satisfying things about Next.js.
You don't configure routes. You create folders.
app/
page.js → "/"
about/
page.js → "/about"
blog/
page.js → "/blog"
[slug]/
page.js → "/blog/any-post-name"
Nested routes
Just nest folders. app/dashboard/settings/page.js gives you /dashboard/settings. That's it.
Dynamic routes
Wrap a folder name in square brackets:
app/blog/[slug]/page.js
Now /blog/hello-world, /blog/my-first-post — all route to the same component. The slug is passed as a prop.
If you've used React Router before, this replaces:
// Old React Router way
<Route path="/blog/:slug" element={<BlogPost />} />
With just... a folder.
Server Components vs Client Components
This is the most important concept in Next.js.
Server Components (Default)
- Run on the server
- Faster performance
- Smaller bundle size
- Can directly fetch data
Client Components
Use this at the top:
"use client"
Needed when you use:
- State (
useState) - Effects (
useEffect) - Event handlers (onClick, etc.)
👉 Rule of thumb:
- Default = Server Component
- Add
"use client"only when needed
Styling in Next.js
Next.js supports multiple styling approaches out of the box:
-
Global CSS —
globals.css, applied app-wide vialayout.js -
CSS Modules —
Button.module.css, scoped to a single component (no class name conflicts) - Tailwind CSS — Works great with Next.js, can be set up during project creation
If you already know Tailwind basics, it integrates seamlessly.
🛠 Running & Building
Basic commands:
npm run dev → development
npm run build → production build
npm run start → run production server
Important understanding:
- dev = fast, for development
- build + start = optimized, for production
🌍 Why Next.js is Used in Real-World Projects
Because it gives:
- SEO-ready: Server rendering means search engines can read your content
- Performance: Automatic code splitting, image optimization, caching
- Full-stack in one project: No need for a separate Express/Node backend for basic APIs
- Vercel deployment: One-click deploy, zero config (Next.js is made by the Vercel team)
- Scales well: Used by large companies like Vercel, TikTok, Twitch, and many others
👉 Companies don’t want to configure everything manually; they want a production-ready system.
Quick Recap
| Concept | One-Line Summary |
|---|---|
| Next.js | React + routing + SSR + API routes |
| App Router | Modern file-based routing in app/
|
| Server Component | Renders on server, default in App Router |
| Client Component | Runs in browser, needs "use client"
|
| File-based routing | Folder = Route |
npm run build |
Creates production-ready app |
Final Thoughts
So to summarize, today was about understanding:
- Why frameworks exist
- Why React alone isn’t always enough
- How Next.js changes the way we think about frontend
👉 Biggest takeaway:
Next.js is not just a tool, it’s a different way of building web apps.
Thanks for reading. Feel free to share your thoughts!
Top comments (0)