Next.js vs React: First Time Using It

July 5, 2026·5 min read

Built this site with Next.js, my first time using it after years of plain React. Goal: understand what Next.js actually adds and why you'd choose it. Here's what I learned and what I'd say if an interviewer asked.

Background

React: a UI library. Renders components in the browser. Gives you components and state management. Nothing else.

Next.js: a framework built on top of React. Adds routing, server rendering, image optimization, and font loading out of the box.

“The server” (in Next.js context): a real computer running Node.js that executes your React code before the browser sees it. When you deploy to Vercel, that server is Vercel's infrastructure (specifically serverless functions that spin up on demand for each request). Locally during npm run dev, it's Node.js on your laptop. In plain React, there is no such server for your app code; the browser is the only thing running React.

CSR (Client-Side Rendering): the browser downloads a nearly-empty HTML shell and a JS bundle, then builds the page entirely in JavaScript. What plain React does by default. No server logic runs after the initial files are served.

SSR (Server-Side Rendering): the server runs your React code on each request and sends the finished HTML to the browser. User sees real content instantly instead of a blank page. Better SEO because crawlers see real HTML.

SSG (Static Site Generation): HTML generated once when you build the app, then served as a plain file from a CDN. Fastest possible, no server logic runs at request time.

Server Components: React components that run only on the server (Vercel's infrastructure or your Node.js host) and never in the browser. Their JavaScript code is never sent to the user. The browser only receives the HTML they produced. Default in the Next.js App Router.

Hydration: after the server sends HTML, React runs in the browser and attaches event listeners so the page becomes interactive. Less JS shipped means faster hydration.

App Router: Next.js 13+ routing system. Every folder in app/ is a route. Every component is a server component unless you opt out.

What I did

1. Used the App Router (not the older Pages Router)
2. Kept every component as a server component by default
3. Only added "use client" where the browser was actually needed: nav (active route detection), theme toggle (state)
4. Used file-based routing: app/blog/page.tsx → /blog, no config
5. Used next/image for the headshot, automatic resizing and lazy loading
6. Used next/font for Geist, zero layout shift, font is inlined at build time

Result

The site ships minimal JS because most components never reach the browser. Routing, image optimization, and fonts required zero config. In plain React I would have needed React Router, a bundler config, and manual image handling to get the same result.

Deep dive

What's the difference between Next.js and React? React is a library; it does one thing (UI components) and leaves everything else to you. Next.js is a framework with opinions: it decides your routing, rendering strategy, and build pipeline. You trade control for speed of setup.

What are server components and why do they matter? Server components run on the server (Vercel's infrastructure in this project's case) and their JavaScript code is never sent to the browser. The browser only receives the finished HTML, so there's less JS to download, parse, and execute on the client. The tradeoff: they can't use useState, useEffect, or browser APIs like window or localStorage. If you need those, add "use client" at the top of the file to opt that component into running in the browser.

When do you use "use client"? Only when you actually need the browser: event handlers, hooks, localStorage, window. Not just because it's easier. Every "use client"is JS you're shipping to the user; it should earn its place.

What is hydration? The server sends pre-rendered HTML so the page appears instantly. Then React runs in the browser and "hydrates" it, attaching event listeners and taking over rendering. With server components, less code is sent to the browser, so hydration is faster.

App Router vs Pages Router? Pages Router is the old system: every file in pages/ is a route, all components are client-side by default. App Router is the new system: files in app/, server components by default, nested layouts via layout.tsx. New projects should use App Router. Pages Router still works but isn't where Next.js is heading.

The folder structure that matters:

app/
  layout.tsx     ← wraps every page (nav, fonts, providers)
  page.tsx       ← the / route
  blog/
    page.tsx     ← the /blog route
    [slug]/
      page.tsx   ← /blog/any-post-slug

What are you actually giving up by picking Next.js? Framework lock-in. Server infrastructure that has to exist somewhere. The mental overhead of server vs client, hydration boundaries, and "use client". You can't just deploy static files to any CDN anymore. For a content site with SEO needs and a normal deploy target, that's a fine trade. For a highly interactive SPA where SEO doesn't matter, plain React (or Vite + React) is simpler and you avoid all of it.

So: Next.js if you need routing, SSR, and optimizations for free. Plain React if you want control and don't need any of that. Server components, hydration, and "use client" all fall out of that first decision.