メインコンテンツへ移動 / Skip to main content

Next.js and Node.jsFrom Historical Origins to Modern Applications

A comprehensive guide to Next.js and Node.js, from their historical origins to modern applications in React-era full-stack development. Practical guide for beginners and experienced developers.

Technology
Published on: September 9, 2025
Read time: 10 min
Author: Pochang Lab
Read time: 10 min

Next.js and Node.js: From Historical Origins to Modern Applications

~This time, let's grasp "React-era full-stack development" in one go~


Introduction (Purpose and Reading Guide)

"Node.js History" → "Next.js Essence" → "Latest Applications" → "Mini Implementation" - we'll learn step by step like a class. This is aimed at those with programming experience but who are returning to or new to Next.js. We'll also clarify the positioning relative to Vue.js/Nuxt and React standalone.

Technical terms will be explained with the flow of definition → analogy → key points. We'll include a practical checklist and sample code at the end.


Chapter 1: Birth and Evolution of Node.js (Historical Glimpses)

What is Node.js?

Node.js is a server-side JavaScript runtime built on top of Google's V8 engine. It features event-driven, asynchronous I/O and is designed to handle many concurrent connections with fewer threads.

💡 Analogy: Think of a restaurant where "one waiter efficiently handles orders for all tables." While it's not great at heavy computation, it's very powerful for web applications with lots of I/O wait time.

Key Historical Points

2009: Initial implementation completed by Ryan Dahl. The cutting-edge asynchronous I/O approach gained attention.

2010: Package manager npm appeared, leading to explosive growth in reusable module distribution.

2014-2015: Governance disputes led to the io.js fork. Later reconciled and unified under Node.js Foundation.

2019: Merged with JS Foundation to form OpenJS Foundation. A system supporting the entire JS ecosystem was established.

Current LTS and Version Status (as of September 2025)

  • Node 18 reached EOL on 2025-04-30 → Migration to 20 or later is recommended
  • Node 24 is scheduled for LTS promotion in October 2025. Consider 20/22/24 for new projects
🎯 Summary: Asynchronous I/O × npm ecosystem pushed web development speed to the next level. Next, we'll look at Next.js, which aims to be the "complete framework" built on this foundation.

Chapter 2: What is Next.js? — Technology that Makes React a "Framework"

Definition of Next.js

Next.js is a full-stack React framework. It integrates as a "toolbox" the parts that are cumbersome to combine with React alone: routing, data fetching, rendering methods (SSG/SSR/ISR), and delivery optimization.

App Router centers around the app/ directory, utilizing React Server Components (RSC) to render and fetch data on the server before sending only the necessary parts to the client.

Why is it Convenient?

💡 Analogy: React standalone is a "component (library)", while Next.js is "blueprints and factory (framework)". It handles everything from wiring (routing) to logistics (build & deploy).

Main Rendering Modes (Terminology)

SSG (Static Site Generation): HTML generation at build time. Fast delivery.

ISR (Incremental Static Regeneration): Based on SSG with automatic regeneration on expiration. Specify seconds with revalidate.

SSR (Server-Side Rendering): Generate HTML on server for each request.

CSR (Client-Side Rendering): Render in browser.

RSC (React Server Components): React that runs on the server. The goal is to reduce unnecessary client JS.


Chapter 3: Latest Status (Quickly Grasp 2025 Keywords)

Next.js 15 (2024-10)

Main features include React 19 support, cache improvements, and Turbopack development experience stabilization. Pages Router maintains React 18 backward compatibility.

Next.js 14 (2023-10)

Server Actions became stable, with Partial Prerendering (preview) and learning course updates.

Current Turbopack Status

Dev server default in Next.js 15 series. next build --turbopack reached beta stage in 15.5 (2025-08). The option to switch to Webpack for compatibility issues still exists.

⚠️ Key Point: While Turbopack is the main candidate for speed improvements, there are reports of compatibility issues with some libraries. It's realistic to temporarily switch back to Webpack if problems occur.

Chapter 4: Next.js Excellence (Essential Benefits)

Maximum Experience with Minimum JS

RSC enables "server-side when possible" approach. Reducing JS sent and speeding up rendering achieves "practical speed" that works on mobile connections and low-end devices.

Integrated Data Fetching and Caching

fetch() options ({ cache, next: { revalidate } }) allow controlling SSG/ISR/SSR behavior with the same API. The boundary between frontend and backend becomes thinner.

Server Actions (Server Functions)

Components can directly call server functions (form submissions, mutations). This reduces cases where separate API routes are needed, shortening the distance between state and processing.

Streaming

Used with Suspense, HTML can be streamed from parts that are ready first. This further improves perceived speed and pairs perfectly with App Router philosophy.

Vercel Affinity

Deployment can be done seamlessly with Git integration → automatic build → global delivery. The "friction" in actual operation is very small.


Chapter 5: Overview of React/Vue/Nuxt Relationships

Positioning of Each Technology

React is a UI library.

Next.js "frameworkizes" React, providing routing, data fetching, and optimization.

Vue.js is a reactive UI library.

Nuxt is the "Next.js-like position" in the Vue ecosystem. The learning axis is similar: file-based routing, SSR/SSG, standardized data fetching.

Technology Selection Considerations

Consider existing assets, hiring talent, hosting, and dependency library maturity. Next.js has an advantage if you value React ecosystem size and Vercel integration.


Chapter 6: 15-Minute "Hands-on" Environment Setup

Prerequisites

Node 20 or higher is recommended (18 is EOL). Version 24 series is scheduled for LTS in October 2025.

Environment Setup Steps

bash
# 0) Prepare Node (e.g., fnm / nvm, any tool)
# Install Node 22 or 20 (LTS range recommended)

# 1) Package manager (pnpm recommended, included with corepack)
corepack enable

# 2) New project (TypeScript / ESLint / Tailwind also configured)
pnpm create next-app@latest my-next-app   --typescript --eslint --tailwind --app --import-alias "@/*"

cd my-next-app

# 3) Start dev server (Next.js 15 has fast dev by default)
pnpm dev
⚠️ Note: If library compatibility errors occur during development, consider temporarily switching to Webpack startup. Latest Turbopack settings can be adjusted with the turbopack key in next.config.{js,ts}.

Chapter 7: App Router Quick Course: Understanding with Samples

Basic Routing (app/ directory)

code
app/
 ├─ layout.tsx        # Shared layout (RSC)
 ├─ page.tsx          # Top page (RSC)
 ├─ about/
 │   └─ page.tsx      # /about
 └─ api/echo/
     └─ route.ts      # /api/echo (Route Handler)

Data Fetching in Server Components (ISR)

tsx
// app/page.tsx  → Default Server Component
export default async function Page() {
  const res = await fetch('https://jsonplaceholder.typicode.com/posts', {
    // Update static generation every 60 seconds (ISR)
    next: { revalidate: 60 }
  });
  const posts = await res.json();
  return (
    <main>
      <h1 className="text-2xl font-bold">Latest Articles</h1>
      <ul>{posts.slice(0,5).map((p:any)=> <li key={p.id}>{p.title}</li>)}</ul>
    </main>
  );
}
💡 Point: fetch() options alone can switch SSG/ISR/SSR behavior.

Client Components (Adding Interactivity)

tsx
// app/components/ThemeToggle.tsx
'use client';

import { useState } from 'react';

export default function ThemeToggle() {
  const [dark, setDark] = useState(false);
  return (
    <button
      onClick={() => setDark(!dark)}
      className="rounded-xl px-4 py-2 border"
    >
      {dark ? '🌙 Dark' : '☀️ Light'}
    </button>
  );
}
💡 Point: Adding 'use client' at the top makes that file run on the browser side (when DOM manipulation or events are needed).

Server Actions (Mutations Without Writing APIs)

tsx
// app/actions.ts
'use server';

export async function addTodo(formData: FormData) {
  const title = String(formData.get('title') || '');
  // Implement server processing like DB saving here
  return { ok: true, title };
}
tsx
// app/todos/page.tsx  → RSC but can call Server Action on form submission
import { addTodo } from '../actions';

export default function Todos() {
  return (
    <form action={addTodo} className="space-x-2">
      <input name="title" placeholder="Todo item" className="border px-2 py-1"/>
      <button className="px-3 py-1 rounded bg-gray-200">Add</button>
    </form>
  );
}
🎯 Point: What used to require creating /api/* routes and POST requests now completes with function call-like feel. This is an important feature that stabilized in Next.js 14.

Route Handlers (APIs Called from External Clients)

ts
// app/api/echo/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function POST(req: NextRequest) {
  const body = await req.json();
  return NextResponse.json({ received: body });
}
💡 Usage: Server Actions excel at "calls from within Next.js", while Route Handlers are suitable when you want to expose APIs to "external clients".

Streaming (Maximizing Perceived Speed)

tsx
// app/slow/page.tsx
import { Suspense } from 'react';

async function SlowPart() {
  await new Promise(r => setTimeout(r, 2000));
  return <div>Delayed content (arrives after 2 seconds)</div>;
}

export default function Page() {
  return (
    <main>
      <h1>Send what can be displayed first</h1>
      <Suspense fallback={<p>Loading...</p>}>
        {/* Stream from server when ready */}
        {/* App Router + RSC + Suspense trinity */}
        {/* (Combine with data fetching in actual use) */}
        <SlowPart />
      </Suspense>
    </main>
  );
}
🚀 Point: "Send skeleton first, then insert slow parts later". This creates a smooth user experience.

Chapter 8: Production Essentials: Cache Design and Data Fetching Practices

Basic Cache Strategy

ISR for static parts: Specify update cycles with next: { revalidate: 300 } etc.

For always-fresh needs: Specify cache: 'no-store' for SSR-like processing.

Fetch on server and assemble with RSC, sending only the minimum necessary to client.

Partial streaming: Absorb heavy computation or external API delays with Suspense.

Server Actions: Safely handle DB writes and validation on server. Perfect match with form submissions.


Chapter 9: Turbopack vs Webpack Practical Decisions (2025 Edition)

Development Environment Choice

Development (dev) is progressing with Turbopack as default for comfort.

Production Build Choice

Production builds with next build --turbopack have reached beta stage (15.5). Don't force it; projects prioritizing stability should choose traditional builds.

Practical Decisions

There are community reports of compatibility issues with some libraries, and Webpack regression is commonly adopted as a workaround in the field.

🎯 Summary: "Fast first, fall back to safe side if problems". Decide the speed vs compatibility tradeoff based on project scale and team experience.

Chapter 10: Deploying to Vercel (3 Steps)

Deployment Steps

  1. Push to GitHub (main branch)
  2. Vercel "New Project" → select repository. Framework auto-detected
  3. Set environment variables (external API keys etc.) → Deploy. Automatic preview/production updates on every push
🚀 Note: /api/* (Route Handlers) and Server Actions work well with Vercel's edge/serverless execution platform, providing scalable configuration out of the box.

Chapter 11: Exercises to Solidify Learning

Exercise A: Blog List + Post Form

Goal: Latest list (ISR 60s) at /, Server Action form at /todos.

Focus: RSC data fetching, Server Actions mutations, Tailwind styling.

Exercise B: API from External Client

Goal: Implement /api/echo with Route Handler and verify with curl.

Learning: Distinction between Server Actions and Route Handlers.


Chapter 12: Common Questions Q&A

Q1. App Router or Pages Router?

A: App Router for new projects. Existing migrations may keep Pages (Next.js 15 has backward compatibility considerations).

Q2. Does RSC Replace Everything?

A: No. Client Component when browser APIs/events are needed. Split with the mindset "server when possible, client when necessary".

Q3. What if Turbopack Has Issues?

A: Review settings, and if still difficult, temporarily switch to Webpack. A configuration where builds use traditional path for stable operation while development uses Turbo to observe is also an option.


Chapter 13: Production Checklist (Save This)

Environment Setup

  • [ ] Use Node 20/22 (or 24 after LTS). 18 is EOL
  • [ ] Use pnpm create next-app@latest with TypeScript + App Router as default

Development Policy

  • [ ] RSC as base, use client only for UI interaction parts
  • [ ] Organize SSG/ISR/SSR with revalidate and cache in fetch()
  • [ ] Keep mutations concise with Server Actions
  • [ ] Boost perceived speed with streaming (Suspense)

Performance Optimization

  • [ ] Turbopack as base, Webpack regression as realistic solution for compatibility issues
  • [ ] Shorten automatic preview → production iteration with Vercel integration
  • [ ] Continuously evaluate JS send volume and TTFB with monitoring (Lighthouse / Web Vitals)

Chapter 14: Important Terms Mini Dictionary

Key Terms

RSC (React Server Components): React that runs on server. Reduces unnecessary client JS, achieving both performance and DX.

Server Actions: Mechanism to directly call server functions from components. Excellent with forms. Stabilized in Next.js 14.

ISR: Automatic updates on expiration for static generation. A compromise between real-time and speed.

Turbopack: Next-generation bundler by Vercel. Fast dev experience, build β in progress (15.5).


Summary (Today's Learning in One Sentence)

Next.js is the React-era full-stack standard that "toolboxizes" RSC × data fetching × delivery optimization. It inherits Node.js's asynchronous philosophy while achieving maximum experience with minimum JS.

Start with the App Router + Server Actions + ISR trio. Remember the realistic solution of "fall back to safe side (Webpack) if problems". This way, you won't be lost even when returning to Next.js after a while.


Appendix: Short Outline

  1. Node.js history (2009 birth → npm → Foundation → OpenJS) and LTS information
  2. Next.js definition: "frameworkizing" React
  3. App Router and RSC/Server Actions/ISR/streaming
  4. 5-minute working samples (fetch revalidate, Server Actions, Route Handlers)
  5. Turbopack vs Webpack realistic decisions
  6. Vercel deployment flow
  7. Production checklist