Learning Next.js - History, Background & Why You Need Next.js

#Introduction

Now that your environment is ready from episode 0, it's time to understand why Next.js exists. Before deciding which framework to use in production, you need to know what problem it solves and why the solution is worth adopting.

Episode 1 dissects the journey of Next.js: from its start as a simple framework for server-side rendering React, its evolution from version 9 to 15, the major role of Vercel in its development, to the series of problems it solves — including an honest comparison with traditional approaches like a pure React SPA.

#History and Evolution of Next.js

#Born from the Need for React SSR

React was originally just a library for building UIs rendered in the browser. The problem: rendered pages only become visible after JavaScript finishes loading — slow for users and bad for search engines. Next.js was born as a framework that lets React be rendered on the server first, producing complete HTML that can be read immediately, which is then brought to life (hydrated) in the browser.

#Evolution from Next.js 9 to 15

The version history of Next.js marks major milestones:

• Next.js 9: dynamic routing, file-system routing, and API Routes.
• Next.js 10: automatic image optimization and built-in i18n support.
• Next.js 11: full support for Webpack 5 and middleware.
• Next.js 12: middleware and experimental React Server Components.
• Next.js 13: the launch of the App Router and new layouts.
• Next.js 14: stable App Router and Server Actions support.
• Next.js 15: Turbopack default for development and async request APIs.

The latest versions introduced a genuinely new architecture, not just cosmetic improvements. That's what you'll study in depth starting from episode 4.

#Vercel's Contribution and the Hybrid Rendering Architecture

#Vercel as the Home of Next.js

Next.js is developed and maintained by Vercel, a platform deployment company. Because Vercel also runs edge infrastructure, Next.js integrates very deeply with the concepts of serverless functions and the edge runtime — topics we'll cover in episodes 20 and 21. This integration makes Next.js more than just a framework; it's part of a complete deployment ecosystem.

#Hybrid Rendering

The main design of Next.js is hybrid rendering: you're not forced to choose one rendering mode for the whole application. Each page can use a different mode as needed — static for pages that rarely change, dynamic for real-time data. This architecture is the answer to the classic trade-off between speed, data freshness, and server cost.

The integration with the platform doesn't stop at deployment. Features like Incremental Static Regeneration and the edge runtime were born from the needs of a platform that serves content from many points. When the framework and the platform are developed by the same team, new features can be released in sync — a speed of innovation that's hard for frameworks with a separate deployment ecosystem to match.

#Problems Next.js Solves

#SSR, SSG, ISR, and CSR in One Framework

Next.js combines four rendering strategies in a single framework:

• SSR: HTML is rendered per-request on the server, fresh but slower.
• SSG: HTML is built at build time, very fast but static.
• ISR: static pages that are updated periodically in the background.
• CSR: rendering in the browser for intensive real-time interactions.

With the right mode per page, you get static speed plus dynamic flexibility.

In practice, you don't always need to think about which mode is being used — Next.js chooses sensible defaults and gives you granular control when needed. The mode can be decided per page, per segment, even per fetch.

It's also important to understand that SSG and ISR both produce pages that are static once built — the difference is only in the update mechanism. SSG stays static forever until the next build, while ISR updates itself in the background according to the revalidate schedule.

This priority order — static first, dynamic only if needed — is a principle you'll use again in episodes 6 and 14.

#File-System Routing and Static Content Optimization

File-system routing removes boilerplate: the app folder determines URLs, and a file named page.tsx becomes a page. This differs from a traditional SPA that needs a separate router library. Next.js also optimizes static content automatically — unused script is counted by a modern bundler, and image assets are optimized at build time.

#Performance, SEO, and Developer Experience

With HTML rendered on the server, search engines read the complete content without executing JavaScript. Combined with automatic per-route code splitting and prefetching when a link becomes visible, performance feels instant. For developers, features like hot reload, built-in TypeScript, and a linter make the feedback loop very fast.

#Comparison with Traditional Approaches

#Pure React SPA vs Next.js

A pure SPA produces a single empty HTML shell; all content is created by JavaScript on the client. The impact: slow initial load time, limited SEO, and pages that don't work if JavaScript fails to load. Next.js solves this by rendering on the server without leaving behind the React component model you know. Check the latest version to make sure you're learning on the right one:

npm view next version

The output of npm view next version shows the latest stable version, for example 15.3.4. The basic structure of a modern Next.js app looks simple:

export default function Home() {
  return (
    <main>
      <h1>Halo dari Next.js</h1>
    </main>
  )
}

The component above is exported as default from app/page.tsx and becomes the / page. It functions as a pure React component, but Next.js is what turns it into server-rendered HTML.

From a team perspective, Next.js also cuts onboarding cost: one framework handles routing, rendering, and deployment, so new team members don't need to learn many separate tools.

There are also cases where Next.js might be overkill — a simple static landing site can use plain static HTML or tooling like Astro. Consider the requirements: if the app needs data, SEO, and React interactivity, Next.js offers the best balance; if it's purely static pages without JavaScript, a lighter framework is a better fit.

#Closing

Here's what to take away:

• Next.js was born to solve the SSR problem with React.
• The evolution from version 9 to 15 marks an architectural leap, not minor changes.
• Vercel plays a key role in the direction of Next.js development.
• Hybrid rendering enables SSG, SSR, ISR, and CSR in one application.
• File-system routing eliminates router boilerplate.
• Server-rendered HTML gives SEO and performance advantages over a pure SPA.

In the next episode, episode 2, we'll dissect core concepts and the main architecture — how things work behind the scenes, the difference between the App Router and Pages Router, the build pipeline, and the roles of the server runtime and the Edge runtime. After this episode, you'll see Next.js not as a black box, but as a system you can control.