Before jumping into writing Next.js code, it’s important to build a strong foundation. This foundation not only helps you write better applications but also helps you answer interview questions confidently and make smarter architectural decisions.

If your “why” isn’t clear, your “how” won’t make sense either. Without understanding the evolution of web technologies, you might even blame Next.js for things you don’t understand—only revealing a lack of knowledge.

So before we dive into coding, let’s travel through time and see how web development evolved from Vanilla JS → React → Next.js.

1. The Vanilla Web: HTML, CSS, JavaScript

Before modern frameworks existed, websites were built using the fundamentals:

• HTML for structure
• CSS for styling
• JavaScript for interactivity

How the traditional web worked

When a user visited a site:

1. The browser sent a request to the server.

2. The server responded with three files:

   • HTML
   • CSS
   • JavaScript

3. The browser:

   • Parsed the HTML
   • Applied CSS
   • Executed JavaScript

4. For every new page, the cycle repeated: new request → new full HTML/CSS/JS files

The downsides

• Heavy client-side processing Slower devices struggled when the browser had to handle large amounts of HTML and JavaScript.

• High bandwidth usage Every page load required downloading complete files again.

• Slow initial load The user sees nothing until the browser receives and processes everything.

This worked fine for simple sites—but it didn’t scale well as websites grew more interactive.

2. The React Era: Component-Based, Client-Side Rendering

React revolutionized UI development with:

• Components
• Virtual DOM
• State + Props
• Reactive rendering

How a React app works

When you visit a React app:

1. The client requests the site content.

2. The server returns:

   • A tiny HTML file
   • A large bundled JavaScript file

3. React uses this JavaScript to:

   • Build the UI on the client
   • Manage updates via the virtual DOM

React Router handles navigation internally, allowing transitions without page refreshes.

The downsides of React alone

• Complexity Components, props, state management, bundling, routing, tooling—there’s a learning curve.

• Client-heavy rendering Everything depends on JavaScript. On slow devices, rendering becomes sluggish.

• SEO limitations Search engines struggle with JavaScript-generated content.

React gave developers a powerful way to build apps, but it didn’t solve everything.

3. The Next.js Way: The Best of Both Worlds

Next.js blends the strengths of both traditional rendering and React.

The biggest innovation? ➡️ You choose where your page is rendered — on the server or in the client.

How Next.js works

When a user visits a Next.js site:

1. The client sends a request.

2. Next.js starts executing React components on the server.

3. It generates:

   • HTML (with content already filled in)
   • CSS
   • JavaScript (only for interactivity)

4. The server sends back fully rendered HTML. The user sees the page instantly.

Then:

5. JavaScript arrives and attaches event handlers in a process called hydration.

Hydration (and the famous hydration errors)

Hydration = attaching interactivity to HTML rendered on the server.

If the HTML on the server doesn’t match what React expects on the client, you get the infamous hydration error.

Next.js manages this process for you, but mismatches can still happen if components behave differently across server and client.

4. Why Next.js Is So Powerful

Next.js gives developers control:

• Render on the server (SSR)
• Render on the client (CSR)
• Pre-render pages ahead of time (SSG)
• Regenerate pages in the background (ISR)

This flexibility lets you:

• Improve performance
• Optimize SEO
• Reduce bundle sizes
• Create dynamic pages easily

Next.js is a modern hybrid framework that adapts to your app’s needs.