LinkedIn Hook

You can build anything with plain React. So why do companies keep putting "Next.js" in every job listing?

Here's the uncomfortable truth: plain React gives you a blank canvas and says "figure it out." Routing? Pick a library. SEO? Good luck with a blank HTML page. Performance? Hope you know code splitting. Server-side logic? Spin up a separate backend.

Next.js hands you all of that on day one — with opinions that save you from yourself.

In this lesson, you'll learn exactly what Next.js solves that React alone cannot, when Next.js is the right choice, when it's overkill, and why interviewers care about this distinction.

Read the full lesson -> [link]

#NextJS #React #WebDevelopment #FrontendDevelopment #InterviewPrep #FullStack #JavaScript

Why Next.js Over Plain React? thumbnail

What You'll Learn

What problems Next.js solves that plain React cannot (SEO, routing, performance, full-stack)
The real difference between a framework and a library — and why Next.js wraps React
When Next.js is the right choice and when it's genuinely overkill
How to bootstrap a Next.js project with create-next-app and what the initial structure looks like

The Kitchen Analogy — Framework vs Library

Imagine you're opening a restaurant.

React is like getting a world-class stove. It's the best stove on the market — powerful, flexible, you can cook anything on it. But that's all you get. You need to find your own kitchen layout, your own refrigerator, your own dishwasher, your own recipes, your own supply chain. You assemble the entire kitchen yourself.

Next.js is like getting a fully designed commercial kitchen. The stove (React) is still at the center, but someone has already designed the kitchen layout (routing), installed the refrigerator (data fetching), added the supply chain (API routes), put up health inspection certificates (SEO), and optimized the workflow so food gets to customers faster (performance). You can still rearrange things, but the defaults are already excellent.

This is the fundamental difference between a library and a framework:

React (library): You call it. You decide the architecture.
Next.js (framework): It calls you. It provides the architecture and you fill in the business logic.

This isn't a value judgment — it's a design philosophy. React gives you maximum freedom. Next.js gives you maximum productivity by making smart choices for you.

What React Alone Cannot Do — The Four Gaps

React is a UI rendering library. It takes state and turns it into DOM elements. That's it. Everything else is your responsibility. Here are the four critical gaps that Next.js fills:

Gap 1: SEO — The Empty HTML Problem

When you build a plain React app (using Vite, Create React App, etc.), the browser receives something like this:

<!-- What Google's crawler sees with plain React (Client-Side Rendering) -->
<!DOCTYPE html>
<html>
  <head>
    <title>My App</title>
  </head>
  <body>
    <!-- This is ALL the HTML content the server sends -->
    <div id="root"></div>

    <!-- The actual content only appears AFTER JavaScript loads and executes -->
    <script src="/static/js/bundle.js"></script>
  </body>
</html>

<!-- Google sees: an empty page with a script tag.
     The content only exists after JavaScript runs in the browser.
     Googlebot CAN execute JS, but it's slower, less reliable,
     and your page enters a "rendering queue" that can take days. -->

With Next.js, the server sends fully rendered HTML:

<!-- What Google's crawler sees with Next.js (Server-Side Rendering) -->
<!DOCTYPE html>
<html>
  <head>
    <title>Top 10 Laptops for Developers in 2025</title>
    <meta name="description" content="Compare the best laptops..." />
    <meta property="og:title" content="Top 10 Laptops..." />
  </head>
  <body>
    <div id="root">
      <!-- Full HTML content is already here -->
      <h1>Top 10 Laptops for Developers in 2025</h1>
      <article>
        <p>Finding the right laptop as a developer means...</p>
        <!-- ...all the content, fully rendered -->
      </article>
    </div>
    <script src="/_next/static/chunks/main.js"></script>
  </body>
</html>

<!-- Google sees: full content immediately.
     No waiting for JavaScript. Instant indexing.
     Social media previews (Open Graph) also work because
     meta tags are rendered server-side. -->

Why this matters for interviews: If an interviewer asks "How would you build a blog or marketing site?", answering "plain React" is a red flag. Search engines need content in the HTML, and plain React delivers an empty shell.

Gap 2: Routing — No Built-In Solution

React has no router. You install react-router-dom, configure routes manually, handle nested layouts yourself, and figure out code splitting per route on your own.

// Plain React — manual routing setup with react-router-dom
import { BrowserRouter, Routes, Route } from "react-router-dom";
import Home from "./pages/Home";
import About from "./pages/About";
import Blog from "./pages/Blog";
import BlogPost from "./pages/BlogPost";
import Layout from "./components/Layout";

// You manually define every route
// You manually set up nested layouts
// You manually handle 404 pages
// You manually configure code splitting with React.lazy()
function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route element={<Layout />}>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
          <Route path="/blog" element={<Blog />} />
          <Route path="/blog/:slug" element={<BlogPost />} />
          <Route path="*" element={<NotFound />} />
        </Route>
      </Routes>
    </BrowserRouter>
  );
}

// Next.js (App Router) — file-based routing, zero configuration
// Just create files. The folder structure IS the routing.

app/
  layout.js          --> wraps ALL pages (root layout)
  page.js            --> renders at /
  about/
    page.js          --> renders at /about
  blog/
    page.js          --> renders at /blog
    [slug]/
      page.js        --> renders at /blog/:slug (dynamic)
  not-found.js       --> automatic 404 page

// No imports. No route configuration. No manual code splitting.
// Each route is automatically code-split.
// Layouts are automatic — nested folders inherit parent layouts.

The key difference: In React, routing is a decision you make and maintain. In Next.js, routing is a convention that just works. Every file in app/ with a page.js becomes a route. Dynamic segments use [brackets]. Layouts wrap their children automatically.

Gap 3: Performance — Manual Optimization vs Built-In

With plain React, performance optimization is your homework:

Code splitting: You manually use React.lazy() and Suspense
Image optimization: You manually compress, resize, and lazy-load images
Font loading: You deal with FOUT (Flash of Unstyled Text) yourself
Bundle size: You manually analyze and reduce your bundle

Next.js handles all of this automatically:

// Plain React — manual image optimization
function ProductImage({ src, alt }) {
  return (
    // No lazy loading by default
    // No responsive sizing
    // No format conversion (WebP/AVIF)
    // No blur placeholder
    // You handle ALL of this yourself
    <img src={src} alt={alt} width={800} height={600} />
  );
}

// Next.js — automatic image optimization with next/image
import Image from "next/image";

function ProductImage({ src, alt }) {
  return (
    // Automatically:
    //   - Lazy loads (only loads when visible)
    //   - Serves responsive sizes based on viewport
    //   - Converts to WebP/AVIF (modern formats, smaller files)
    //   - Generates blur placeholder while loading
    //   - Prevents layout shift (Cumulative Layout Shift = 0)
    <Image
      src={src}
      alt={alt}
      width={800}
      height={600}
      placeholder="blur"
      priority={false}  // Set true for above-the-fold images
    />
  );
}

// Output: Next.js generates multiple sizes at build time
// and serves the optimal one based on the user's device.
// A phone gets a 400px image. A desktop gets 800px.
// Format is WebP if the browser supports it.

Gap 4: Full-Stack Capability — API Routes & Server Logic

Plain React is frontend-only. If you need an API, you build a separate Express/Fastify/NestJS backend, deploy it separately, handle CORS, manage two repositories, and coordinate deployments.

Next.js is a full-stack framework. Your API lives alongside your frontend:

// app/api/users/route.ts — a full API endpoint inside your Next.js app
// No separate backend server needed. No CORS issues. One deployment.

import { NextRequest, NextResponse } from "next/server";

// Handles GET /api/users
export async function GET() {
  // You can directly query your database here
  // This code NEVER runs in the browser — it's server-only
  const users = await db.user.findMany();

  return NextResponse.json(users);
}

// Handles POST /api/users
export async function POST(request: NextRequest) {
  const body = await request.json();

  const newUser = await db.user.create({
    data: { name: body.name, email: body.email },
  });

  return NextResponse.json(newUser, { status: 201 });
}

Why this matters: In interviews, if someone asks "How would you build a full-stack app?", the answer "Next.js with server actions and route handlers" shows you understand the modern full-stack story. You don't always need a separate backend.

Why Next.js Over Plain React? visual 1

Framework vs Library — The Architectural Difference

This distinction is an interview staple. Let's be precise:

Aspect	React (Library)	Next.js (Framework)
Control flow	You call React	Next.js calls your code
Routing	You choose and configure	Built-in (file-based)
Rendering	Client-side only	SSR, SSG, ISR, CSR
Data fetching	You choose (fetch, axios, SWR)	Built-in with caching layers
API layer	Separate backend needed	Route handlers + server actions
Build tooling	You configure (Vite, Webpack)	Preconfigured (Turbopack/Webpack)
Deployment	Static hosting only	Vercel, Node.js server, Docker, static export
SEO	Manual, difficult	Built-in metadata API, SSR

The Inversion of Control: When you use React, your main.js is the entry point. You decide when to render, how to route, what to fetch. When you use Next.js, the framework is the entry point. It decides when to render your pages, how routes map to files, and when data fetching happens. You write the components and the business logic — Next.js orchestrates the rest.

This is called Inversion of Control (IoC), and it's the defining characteristic of a framework vs a library.

LIBRARY (React):
  Your Code --calls--> React.render()
  Your Code --calls--> ReactRouter
  Your Code --calls--> fetchData()
  Your Code controls the flow.

FRAMEWORK (Next.js):
  Next.js --calls--> your page.js
  Next.js --calls--> your layout.js
  Next.js --calls--> your route.ts
  Next.js controls the flow. You fill in the blanks.

When Next.js Is the Right Choice

Next.js shines when your project needs any of the following:

SEO matters — blogs, e-commerce, marketing sites, documentation, any content that must be indexed by search engines
Performance is critical — landing pages, media sites, anything where Time to First Byte and Largest Contentful Paint directly affect business metrics
Full-stack in one repo — you want your API, your server logic, and your frontend in one codebase, deployed together
Multiple rendering strategies — some pages are static (marketing), some are dynamic (dashboard), some need real-time data (feeds)
Team productivity — conventions over configuration means fewer debates about folder structure, routing, and tooling

Real examples: Vercel.com, Hulu, TikTok (web), Notion, Twitch, Nike, the Washington Post — all use Next.js.

When Next.js Is Overkill

Not every project needs Next.js. Here's when plain React (or another tool) makes more sense:

Internal dashboards / admin panels — No SEO needed. No public users. CSR with Vite + React is simpler and deploys as static files.
Highly interactive SPAs — Real-time collaboration tools (like Figma), complex editors, or canvas-heavy apps where the entire experience is client-side interactivity. SSR adds complexity with zero benefit.
Micro-frontends or embedded widgets — If you're building a widget to embed in someone else's page, you need a small, self-contained bundle — not a server framework.
Learning React — If someone is new to React, adding Next.js concepts (server components, SSR, caching layers) creates confusion. Learn React first, then Next.js.
Static sites with no dynamic content — A simple portfolio with 5 pages might be better served by Astro or plain HTML. Next.js works, but it's more machinery than needed.

Interview gold: When an interviewer asks "Would you use Next.js for this project?", the best answers acknowledge trade-offs. Saying "Next.js for everything" is as bad as saying "never Next.js." Show you can evaluate.

Getting Started — create-next-app

# Create a new Next.js project with the latest version
npx create-next-app@latest my-app

# The CLI asks you these questions:
# Would you like to use TypeScript?           --> Yes (recommended)
# Would you like to use ESLint?               --> Yes
# Would you like to use Tailwind CSS?         --> Yes (optional)
# Would you like your code inside a `src/` directory? --> Yes (optional)
# Would you like to use App Router?           --> Yes (recommended for new projects)
# Would you like to use Turbopack for `next dev`?   --> Yes (faster dev server)
# Would you like to customize the import alias? --> No (default @/* is fine)

# The generated project structure (App Router):

my-app/
  app/
    layout.tsx        # Root layout — wraps every page
    page.tsx          # Home page (renders at /)
    globals.css       # Global styles
    favicon.ico       # Site favicon
  public/             # Static assets (images, fonts)
  next.config.ts      # Next.js configuration
  package.json        # Dependencies and scripts
  tsconfig.json       # TypeScript configuration
  tailwind.config.ts  # Tailwind configuration (if selected)

# Key scripts:
#   npm run dev    --> starts dev server (localhost:3000)
#   npm run build  --> creates production build
#   npm run start  --> runs production server

What happens under the hood when you run npm run dev:

Next.js starts a Node.js server on port 3000
It reads the app/ directory and maps files to routes
It sets up Hot Module Replacement (HMR) so changes appear instantly
It compiles TypeScript, JSX, and CSS on-the-fly
It handles both server-side and client-side rendering automatically

This is the zero-configuration promise. You write components, Next.js handles everything else.

Why Next.js Over Plain React? visual 2

Common Mistakes

Saying "Next.js replaces React." Next.js does not replace React — it wraps React. Every Next.js app is a React app. Every React concept (components, hooks, state, props) still applies. Next.js adds server-side rendering, routing, and tooling on top of React. In an interview, say "Next.js is a framework built on top of React" — never "instead of React."
Using Next.js for every project without evaluating trade-offs. Next.js adds a Node.js server dependency (unless you use static export). For a simple SPA dashboard that doesn't need SEO, Vite + React deploys as static files to any CDN with zero server costs. Choosing the right tool for the right job is what interviewers want to hear.
Confusing CSR, SSR, and SSG before understanding why they exist. Many developers memorize the acronyms without understanding the underlying problem (SEO, performance, data freshness). Always start from the problem: "My page needs to be indexed by Google, so I need the HTML pre-rendered on the server. That's SSR." The rendering strategy follows from the requirement, not the other way around.

Interview Questions

Q1: What problems does Next.js solve that plain React doesn't?

(Covered in the "Four Gaps" section above — SEO, routing, performance, full-stack.)

Q2: Is Next.js a replacement for React? Explain the relationship.

(Covered in Common Mistakes above — Next.js wraps React, doesn't replace it.)

Q3: What is the difference between a library and a framework? Where do React and Next.js fall?

(Covered in the "Framework vs Library" section above.)

Q4: When would you NOT choose Next.js for a project?

(Covered in the "When Next.js Is Overkill" section above.)

Q5: What is file-based routing and how does it differ from manual routing in React?

In Next.js (App Router), the folder structure inside app/ directly maps to URL routes. Creating app/about/page.tsx automatically creates the /about route. Dynamic segments use bracket syntax: app/blog/[slug]/page.tsx maps to /blog/anything. There's no route configuration file. In plain React, you manually define routes using a library like React Router, specifying each path and its corresponding component in code. File-based routing eliminates boilerplate, enforces convention, and enables automatic code splitting per route — each page only loads the JavaScript it needs.

Quick Reference -- Cheat Sheet

+--------------------------------------------------------------+
|              React vs Next.js — Decision Guide               |
+--------------------------------------------------------------+
|                                                              |
|  CHOOSE PLAIN REACT (Vite) WHEN:                            |
|    - Internal tool / admin dashboard                         |
|    - No SEO needed                                           |
|    - Pure SPA with heavy client interactivity                |
|    - Embedding widgets in other sites                        |
|    - Learning React fundamentals                             |
|                                                              |
|  CHOOSE NEXT.JS WHEN:                                        |
|    - SEO matters (blog, e-commerce, marketing)               |
|    - Performance is a business metric                        |
|    - You need SSR, SSG, or ISR                               |
|    - You want full-stack in one repo                         |
|    - Team needs conventions over configuration               |
|                                                              |
+--------------------------------------------------------------+

Feature	Plain React	Next.js
Rendering	CSR only	SSR + SSG + ISR + CSR
Routing	Manual (react-router)	File-based (automatic)
SEO	Poor (empty HTML)	Excellent (pre-rendered HTML)
API	Separate backend	Built-in route handlers
Code splitting	Manual (React.lazy)	Automatic per route
Image optimization	Manual	Built-in (next/image)
Deployment	Static hosting	Server, static, or edge
Configuration	You decide everything	Convention-based defaults

Next: Lesson 1.2 -- App Router vs Pages Router ->

This is Lesson 1.1 of the Next.js Interview Prep Course -- 8 chapters, 33 lessons.

Why Next.js Over Plain React?