前端框架深度指南

前言

你已經學會了 HTML、CSS 和 JavaScript 基礎，能做出簡單的網頁了。但隨著網頁功能越來越複雜，你可能會發現：用原生 JavaScript 寫程式碼變得很難維護，改一處要動很多地方，多人協作時經常衝突。

這就是我們需要前端框架的原因——它讓程式碼更有條理、更易維護、更高效開發。在 vibecoding 裡，AI 會幫你寫大部分程式碼。但你至少得能看懂不同框架的程式碼風格，知道它們的優缺點，這樣 AI 才能幫你選擇最合適的技術棧。

讀完這篇，你就能：

理解前端技術為什麼要不斷演進
知道 Vue、React、Svelte、Angular 各有什麼特點
懂得「資料驅動」、「元件化」這些核心概念
能根據專案選擇合適的框架

這篇文章會帶你學什麼？

章節	內容	學完能幹嘛
第 1 章	為什麼要關注前端演進	明白技術演進是為了解決什麼問題
第 2 章	靜態網頁時代	了解最早期的網頁開發方式
第 3 章	jQuery 時代	理解「命令式」程式設計的痛點
第 4 章	Vue/React 時代	掌握「宣告式」和「資料驅動」思想
第 5 章	渲染策略	知道 CSR、SSR、SSG 的區別和適用場景
第 6 章	工程化工具	理解 Webpack、Vite 等建構工具的作用

每一章都從「為什麼需要這個技術」開始，讓你理解技術演進背後的邏輯。

1. 為什麼要關注前端演進史？

🤔 核心問題

為什麼網頁越來越複雜？前端技術為什麼要不斷演進？ 這個問題會帶你理解從簡單網頁到現代 Web 應用程式的技術演變之路。

1.1 從「電子海報」到「桌面應用程式」

想像一下你在街上看到的海報：

✅ 有內容（文字、圖片）
✅ 有設計（顏色、排版）
❌ 但你跟它說話，它不會回應
❌ 你點擊某個地方，不會發生什麼

最早的網頁就是這樣的「電子海報」：只能看、不能改、內容固定。

現代網頁完全不同了。它們像桌面應用程式（VS Code、Figma）：

✅ 可以編輯文件、畫圖、玩遊戲
✅ 即時回應你的每個操作
✅ 甚至可以離線工作

這種轉變的核心原因：網頁的功能越來越複雜，需要更高效的技術和開發方式。

1.2 一個生活的比喻：蓋房子

前端技術的演進，就像蓋房子方式的進化：

時代	🏠 蓋房比喻	實際特點	優缺點
2000s	貼海報	靜態網頁，寫好 HTML 就行	✅ 簡單 ❌ 不能互動
2010s	請工人手動裝修	jQuery 時代，手動操作每個元素	✅ 能互動 ❌ 程式碼亂、難維護
2020s	用樂高搭房子	Vue/React 時代，元件化開發	✅ 高效、可維護 ❌ 學習曲線

💡 從表格中你能看到什麼？

階段一 → 階段二：從「不能動」到「能動」。這是質的飛躍——網頁開始有互動，但代價是程式碼變得混亂。

階段二 → 階段三：從「能用」到「好用」。元件化讓程式碼像積木一樣可複用，大幅提升開發效率。

核心思想：技術演進不是「為了新而新」，而是為了解決上一個階段的痛點。

2. 第一階段：靜態網頁與「切圖」（2000s）

🤔 核心問題

最早的網頁是什麼樣的？為什麼那時候不需要框架？ 理解這個階段的局限性，才能明白後來技術演進的必要性。

I. The Static Era

Web pages were just digital documents. The server sent HTML, and the browser rendered it. Want new content? Refresh the whole page.

index.html

<html>
<body>
  <h1>Hello World</h1>
  <p>Static content served by server.</p>
</body>
</html>

Architecture Pattern

📄 HTML (Content)

↓

🌍 Browser (Display)

Server sends complete HTML

2.1 這個時代是什麼樣的？

開發方式：

寫幾個 HTML 檔案
內嵌一些 CSS 和 JavaScript
直接把檔案拖到瀏覽器就能看效果
上傳資料夾到伺服器就完成部署

特點：

✅ 優點：簡單直接，沒有學習成本，寫完就能跑
❌ 缺點：無法實現複雜互動，程式碼一多就亂

查看當時的專案結構

project/
├── index.html
├── login.html
├── css/
│   ├── bootstrap.css
│   └── custom.css
├── js/
│   ├── jquery.js
│   └── app.js
└── images/

遇到的問題：

全域變數汙染：所有變數都在全域命名空間，容易互相覆蓋
依賴管理混亂：必須按正確順序載入 JS 檔案，否則會報錯
程式碼難以複用：想複用某個功能，只能複製貼上

2.2 「切圖」是什麼？

你可能聽說過「切圖」這個詞。它是早期前端的主要工作：

什麼是切圖？

設計師用 Photoshop 設計好頁面 → 前端把設計切成小圖片 → 用 HTML 把圖片拼成頁面

為什麼這麼慢？

網頁上的每張小圖片，瀏覽器都要發一次網路請求。請求越多，載入越慢。

👇 動手試試看：觀察圖片請求對載入效能的影響

Slice count:12 images Merge into a sprite

Total requests

Estimated load time

750 ms

💡 雪碧圖（Sprite）

為了減少請求數，出現了「雪碧圖」技術：把很多小圖合成一張大圖。

優點是請求數變少，缺點是製作和維護都很麻煩。

這個階段的教訓：請求太多是效能大敵。

3. 第二階段：jQuery 時代 - 「手動搬磚」（2010s）

🤔 核心問題

為什麼需要 jQuery？它解決了什麼問題，又帶來了什麼新問題？ 理解 jQuery 的局限性，才能明白 Vue/React 的價值。

3.1 為什麼需要 jQuery？

隨著網頁變複雜，原生 JavaScript 的問題暴露出來：

❌ API 繁瑣：簡單的操作也要寫很多程式碼
❌ 瀏覽器相容：不同瀏覽器的 API 不一樣，要寫很多相容程式碼
❌ 選擇器弱：找元素很麻煩

jQuery 誕生了。它讓 JavaScript 變得簡單：

javascript

// 原生 JavaScript（繁瑣）
const element = document.getElementById('title')

// jQuery（簡潔）
const element = $('#title')

3.2 jQuery 的思路：親手改頁面

jQuery 的核心思路是命令式：你告訴瀏覽器「怎麼做」。

javascript

// 找到標題元素
$('#title').text('新標題')

// 找到按鈕並禁用
$('#submit-btn').attr('disabled', true)

// 找到列表並新增一項
$('ul').append('<li>新專案</li>')

問題：你需要記住頁面上有哪些元素，每次資料變化都要手動更新所有相關元素。

👇 動手試試看：對比 jQuery 和資料驅動的方式

jQuery mindset: update DOM everywhere

Cart page count: 1

Checkout button:

Simulated commands

✅ All three places are consistent.

Command log

(No actions yet)

Vue/React mindset: update State only

Cart page count: 1

Checkout button:

You only need one action

When State changes, all three UI locations sync automatically. You do not manually find and update DOM nodes.

Two terms here

DOM: The page structure inside the browser, including buttons, text, and images

State: Page data, such as the cart count

⚠️ jQuery 的痛點

想像你在做一個購物車：

javascript

// 使用者點擊「加入購物車」
function addToCart() {
  cartCount++ // 資料變化

  // 你要手動更新所有相關地方
  $('#cart-count').text(cartCount) // 右上角小紅點
  $('#cart-page-count').text(cartCount) // 購物車頁面
  $('#checkout-price').text(calculatePrice()) // 結算按鈕

  // 如果漏了一個地方，頁面就不一致了！
}

這就是「手動搬磚」的代價：容易出錯，難以維護。

3.3 行動裝置普及：回應式設計的出現

這個階段還有一個重要變化：手機和平板開始流行。

網頁必須適配不同螢幕。這需要回應式版面：同一套 HTML/CSS，自動根據螢幕寬度變換版面。

回應式版面的核心：媒體查詢（Media Query）

css

/* 電腦螢幕（大於 640px） */
@media (min-width: 640px) {
  .container {
    display: flex;
  }
}

/* 手機螢幕（小於 640px） */
@media (max-width: 640px) {
  .container {
    display: block;
  }
}

👇 動手試試看：調整瀏覽器寬度，觀察回應式版面的效果

Viewport width:860 px

Card 1

Card 2

Card 3

Card 4

Card 5

Card 6

Current columns:2

💡 回應式就像「智慧相框」

想像你在不同房間看同一張照片：

在大客廳（電腦螢幕），照片可以擺大一些，旁邊還能放其他裝飾品
在小臥室（手機螢幕），照片需要縮小，其他裝飾品要收起來

回應式版面就是「智慧相框」，它會自動根據房間大小調整展示方式。

4. 第三階段：從「手動搬磚」到「資料驅動」（Vue/React）

🤔 核心問題

為什麼需要 Vue/React？它們和 jQuery 的本質區別是什麼？ 理解「宣告式」和「資料驅動」，是掌握現代前端框架的關鍵。

4.1 為什麼需要新框架？

jQuery 時代的問題累積到一定程度：

程式碼一多就亂：到處都是 DOM 操作，難以維護
容易出 bug：漏更新一個地方，頁面就不一致
協作困難：多人修改同一個檔案，容易衝突

Vue / React 的核心思路：只改資料，頁面自動更新。

4.2 Vue/React 的思路：宣告式 UI

jQuery（命令式）：

javascript

// 你要告訴瀏覽器每一步怎麼做
$('#title').text('新標題')
$('#title').css('color', 'red')
$('#title').show()

Vue（宣告式）：

javascript

// 你只需告訴瀏覽器「要顯示什麼」
data() {
  return {
    title: "新標題",
    color: "red",
    visible: true
  }
}

👇 動手試試看：對比命令式和宣告式的區別

🔄Imperative vs DeclarativeTwo programming mindsets: manual operations vs automatic response

ImperativejQuery style - manual operations

// Manually operate the DOM
 $('#count').text(val);
 if (val > 5) $('#msg').show();

Count: 0

Ready.

DeclarativeVue/React style - automatic response

// Bind data only
{{ count }}
 <div v-if="count > 5">...</div>

Count: 0

Framework handles DOM updates automatically.

💡Core idea:Imperative code tells the computer how to do each step. Declarative code tells it the desired result and lets the framework handle the updates.

💡 命令式 vs 宣告式

就像畫一幅畫：

命令式：你告訴畫家「拿起筆，蘸紅顏料，在座標（10,10）畫一個圈」
宣告式：你直接給畫家一張照片，「給我畫成這樣」

Vue/React 就是「宣告式」：你描述「頁面長什麼樣」，框架負責「怎麼把它畫出來」。

4.3 元件化：像搭樂高一樣寫頁面

Vue / React 最強大的特性是元件化：把頁面拆成一個個獨立的「積木」。

想像一下你在搭樂高：

你不需要「從頭開始雕刻每一塊積木」（從頭寫 HTML/CSS）
你只需要「按說明書把積木拼在一起」（把元件組合起來）
每個積木都是獨立的，你可以在不同的套裝裡重複使用

元件的好處：

複用：寫一個「商品卡片」元件，可以用 100 次
封裝：元件內部的狀態不影響別人
維護：修改一個元件，所有用到它的地方都會更新

💡 識別技巧

看到 <ComponentName /> → 這是一個元件
看到 import xxx from './xxx.vue' → 在匯入一個元件
看到 props: {...} → 元件接收的參數
看到 emit('xxx') → 元件向父元件發送事件

4.4 SPA：單頁應用程式的誕生

Vue / React 時代還有一個重要變化：從 MPA 到 SPA。

MPA（Multi-Page Application）：

點一個連結 → 整頁重新整理 → 顯示新頁面
就像翻書：每翻一頁都要把舊書合上、去書架拿新書

SPA（Single-Page Application）：

點一個連結 → 只重新整理內容區域 → 頁面不重新整理
就像同一本書裡換章節：只擦掉舊內容、寫上新內容

👇 動手試試看：體驗 MPA 和 SPA 的區別

Current page:Home

MPA: each navigation performs a full-page reload.

SPA 的優點：

✅ 體驗絲滑：頁面切換快
✅ 狀態好管理：輸入的內容、捲動位置都在
❌ 首屏可能慢：需要先下載 JavaScript
❌ SEO 要額外處理：搜尋引擎可能抓不到內容（需要 SSR/SSG）

5. 渲染策略：從 CSR 到 SSR/SSG

🤔 核心問題

頁面是在伺服器生成，還是在瀏覽器生成？ 不同渲染策略各有優劣，選擇合適的策略對效能和 SEO 至關重要。

CSR（Client-Side Rendering）客戶端渲染：

瀏覽器下載 JavaScript → 執行程式碼 → 生成頁面
優點：互動流暢，伺服器壓力小
缺點：首屏慢，不利於 SEO

SSR（Server-Side Rendering）伺服器端渲染：

伺服器生成 HTML → 發給瀏覽器 → 瀏覽器直接顯示
優點：首屏快，利於 SEO
缺點：伺服器壓力大，實作複雜

SSG（Static Site Generation）靜態站點生成：

建構時生成所有頁面的 HTML
優點：極快，完全靜態，CDN 友好
缺點：不適合動態內容

👇 動手試試看：對比不同渲染策略的特點

TTFB

450 ms

Time to interactive

1600 ms

SEO friendly

Fair

The page renders only after JavaScript loads and fetches data.

💡 如何選擇？

內容網站（部落格、文件）：優先 SSG
需要 SEO 的動態網站（電商、新聞）：使用 SSR
後臺管理系統：使用 CSR
混合需求：考慮 Nuxt/Next.js 的混合渲染

6. 第四階段：工程化與建構工具（2015s-2020s）

🤔 核心問題

為什麼前端需要「工程化」？建構工具到底在做什麼？ 理解工程化，才能看懂現代前端專案的工作流程。

6.1 為什麼需要「工程化」？

前端專案越來越大，不能再靠「手動引入腳本」。

工程化就是用工具和規範，讓開發更高效、程式碼更可靠、協作更順暢。

💡 工程化 = 從「手工作坊」到「現代化工廠」

想像一下你在家做飯 vs 開餐廳：

在家做飯：想吃什麼就做什麼，很自由
開餐廳：需要標準化的菜譜、規範的操作流程、統一的原材料採購

前端開發也一樣：

小專案：怎麼寫都行
大專案：需要統一的程式碼規範、自動化工具、標準化流程

6.2 建構工具：Webpack → Vite

Webpack（傳統）：

工作方式：先打包，後服務
啟動時：打包所有程式碼 → 啟動伺服器
問題：慢。專案越大，啟動越慢（可能要等 30 秒）

Vite（現代）：

工作方式：按需編譯
啟動時：不打包，直接啟動伺服器
瀏覽器請求哪個檔案，就即時編譯哪個
優勢：快。通常 1 秒內啟動

對比項	Webpack	Vite	提升
冷啟動	30s+	<1s	快 30 倍
熱更新	3-5s	<100ms	快 30 倍
設定檔	幾百行	幾十行	大幅簡化

💡 為什麼 Vite 這麼快？

Webpack 就像整備家當搬家：先把所有東西打包，再出門。

Vite 就像輕裝旅行：只帶必需品，用到什麼再買什麼。

在開發環境，大多數時候你只需要修改幾個檔案，Vite 只編譯這幾個檔案，當然快。

7. 主流框架對比

🤔 核心問題

Vue、React、Svelte、Angular 各有什麼特點？如何選擇適合自己的框架？ 了解它們的設計理念和使用場景，才能做出明智的選擇。

7.1 四大框架對比

特性	Vue	React	Svelte	Angular
設計理念	漸進式框架	UI 函式庫	編譯時框架	完整平臺
學習曲線	⭐⭐ 簡單	⭐⭐⭐ 中等	⭐⭐ 簡單	⭐⭐⭐⭐ 陡峭
效能	快	快	極快	快
生態系統	完善	最完善	成長中	完善
套件大小	小	中等	最小	大
適合場景	中小型專案	大型專案	效能要求高	企業級應用
公司支援	尤雨溪（獨立）	Meta	社群	Google

7.2 Vue：漸進式框架

核心理念：漸進式採用，可以只用一部分，也可以用全家桶

vue

<template>
  <div>{{ message }}</div>
</template>

<script>
export default {
  data() {
    return {
      message: 'Hello Vue'
    }
  }
}
</script>

優點：

✅ 學習曲線平緩，中文文件完善
✅ 模板語法直觀，易於理解
✅ 單檔案元件（.vue）結構清晰
✅ 適合快速開發

缺點：

❌ 大型專案的狀態管理需要額外學習 Vuex/Pinia
❌ 靈活性略遜於 React

適用場景：

中小型 Web 應用
快速原型開發
中文團隊（文件友好）

7.3 React：UI 函式庫

核心理念：只負責視圖層，其他問題交給社群

jsx

function App() {
  const [message, setMessage] = useState('Hello React')
  return <div>{message}</div>
}

優點：

✅ 生態系統最完善，元件庫豐富
✅ JSX 語法靈活，表達能力強大
✅ 虛擬 DOM 效能優秀
✅ 適合大型專案

缺點：

❌ 學習曲線較陡，需要掌握額外概念
❌ 需要自己選擇和搭配各種函式庫
❌ JSX 需要編譯，不能直接在瀏覽器執行

適用場景：

大型複雜應用
需要豐富生態的專案
跨平臺開發（React Native）

7.4 Svelte：編譯時框架

核心理念：沒有虛擬 DOM，編譯時將元件轉換為高效的原生程式碼

svelte

<script>
  let message = 'Hello Svelte'
</script>

<div>{message}</div>

優點：

✅ 效能最優（無虛擬 DOM 執行時開銷）
✅ 套件體積最小
✅ 語法簡單直觀
✅ 響應式系統天然支援

缺點：

❌ 生態相對較小
❌ 社群規模不如 Vue/React
❌ 第三方函式庫較少

適用場景：

效能要求極高的應用程式
套件體積敏感的專案
願意嘗試新技術的團隊

7.5 Angular：完整平臺

核心理念：提供完整的解決方案，開箱即用

typescript

@Component({
  selector: 'app-root',
  template: '<div>{{ message }}</div>'
})
export class AppComponent {
  message = 'Hello Angular'
}

優點：

✅ 功能完整，路由、HTTP、表單全都有
✅ TypeScript 原生支援
✅ 適合大型團隊和專案
✅ 程式碼規範統一

缺點：

❌ 學習曲線陡峭
❌ 概念多，複雜度高
❌ 套件體積大
❌ 不適合小型專案

適用場景：

大型企業級應用
需要嚴格規範的團隊
已有 TypeScript 技術棧的專案

8. 總結：演進的本質

前端技術的演進，本質上是在解決兩個問題：

8.1 效率：從手動到自動

時代	開發方式	效率
2000s	手寫 HTML/CSS/JS	⭐
2010s	jQuery + 手動 DOM 操作	⭐⭐
2020s	Vue/React + 資料驅動	⭐⭐⭐
現在	元件化 + 工程化 + 自動化	⭐⭐⭐⭐⭐

8.2 規模：從個人到團隊

時代	專案規模	協作方式
2000s	幾個檔案	單人就能維護
2010s	幾十個檔案	小團隊，容易衝突
2020s	幾百個檔案	中團隊，需要規範
現在	幾千個檔案	大團隊，需要完整工程體系

9. 學習路線圖

9.1 如果你是零基礎

第 1 步：HTML/CSS/JavaScript 基礎

理解網頁的三大基石
能寫出簡單的靜態頁面

第 2 步：學習一個框架（Vue 推薦）

理解「資料驅動」的思想
掌握元件化開發

第 3 步：實戰專案

做一個完整的單頁應用程式
熟悉路由、狀態管理、API 呼叫

9.2 如果你有基礎

進階方向：

工程化：學習 Vite/Webpack，理解建構流程
效能最佳化：學習懶載入、程式碼分割、快取策略
TypeScript：為程式碼加上型別，提升可靠性
伺服器端渲染：學習 Nuxt/Next.js，解決 SEO 和首屏問題

10. 你現在應該能識別的程式碼

透過閱讀本章，你應該能夠：

✅ 理解前端技術演進的脈絡和原因
✅ 區分 Vue、React、Svelte、Angular 的特點
✅ 理解「命令式」和「宣告式」的區別
✅ 掌握「資料驅動」的核心思想
✅ 知道元件化開發的價值
✅ 了解 CSR、SSR、SSG 的適用場景
✅ 理解建構工具（Webpack、Vite）的作用
✅ 能根據專案選擇合適的框架和技術棧

💡 實際應用

當你用 AI 做專案時，你可以這樣告訴它：

「這是一個需要 SEO 的部落格網站，用 Nuxt（Vue 的 SSR 框架）」
「這是一個後臺管理系統，用 Vue + Element Plus，不需要 SSR」
「這是一個效能要求高的 Web 應用程式，考慮使用 Svelte」
「專案已經用 React 了，繼續用 React 生態的函式庫」

名詞速查表

名詞	英文	用人話解釋
DOM	Document Object Model	文件物件模型。用物件樹表示頁面，可被 JS 讀寫。
jQuery	-	早期流行的 JS 函式庫，簡化了 DOM 操作。
Vue/React	-	現代前端框架，採用資料驅動和元件化開發。
元件	Component	可複用的 UI 單元，如按鈕、卡片、導航欄。
MPA	Multi-Page Application	多頁應用。每次跳轉都重新載入整個頁面。
SPA	Single-Page Application	單頁應用。只載入一次，後續切換不重新整理頁面。
路由	Routing	管理頁面之間切換的規則和過程。
SSR	Server-Side Rendering	伺服器端渲染。伺服器生成 HTML 後發給瀏覽器。
SSG	Static Site Generation	靜態站點生成。建構時預渲染頁面為靜態 HTML。
CSR	Client-Side Rendering	客戶端渲染。瀏覽器透過 JS 生成頁面。
Webpack	-	傳統打包工具，先打包後服務。
Vite	-	現代建構工具，按需編譯，速度極快。
回應式	Responsive Design	頁面自動適配不同螢幕尺寸的設計。
媒體查詢	Media Query	CSS 的條件判斷，根據螢幕寬度應用不同樣式。
命令式	Imperative	告訴程式「怎麼做」。
宣告式	Declarative	告訴程式「要什麼」。
資料驅動	Data-Driven	只修改資料，介面自動更新。
Tree Shaking	-	搖樹最佳化。自動移除未使用的程式碼，減小套件體積。
程式碼分割	Code Splitting	把程式碼分成多個小塊，按需載入。

前端框架深度指南 ​

1. 為什麼要關注前端演進史？ ​

1.1 從「電子海報」到「桌面應用程式」 ​

1.2 一個生活的比喻：蓋房子 ​

2. 第一階段：靜態網頁與「切圖」（2000s） ​

I. The Static Era

2.1 這個時代是什麼樣的？ ​

2.2 「切圖」是什麼？ ​

3. 第二階段：jQuery 時代 - 「手動搬磚」（2010s） ​

3.1 為什麼需要 jQuery？ ​

3.2 jQuery 的思路：親手改頁面 ​

3.3 行動裝置普及：回應式設計的出現 ​

4. 第三階段：從「手動搬磚」到「資料驅動」（Vue/React） ​

4.1 為什麼需要新框架？ ​

4.2 Vue/React 的思路：宣告式 UI ​

4.3 元件化：像搭樂高一樣寫頁面 ​

4.4 SPA：單頁應用程式的誕生 ​

5. 渲染策略：從 CSR 到 SSR/SSG ​

6. 第四階段：工程化與建構工具（2015s-2020s） ​

6.1 為什麼需要「工程化」？ ​

6.2 建構工具：Webpack → Vite ​

7. 主流框架對比 ​

7.1 四大框架對比 ​

7.2 Vue：漸進式框架 ​

7.3 React：UI 函式庫 ​

7.4 Svelte：編譯時框架 ​

7.5 Angular：完整平臺 ​

8. 總結：演進的本質 ​

8.1 效率：從手動到自動 ​

8.2 規模：從個人到團隊 ​

9. 學習路線圖 ​

9.1 如果你是零基礎 ​

9.2 如果你有基礎 ​

10. 你現在應該能識別的程式碼 ​

名詞速查表 ​

前端框架深度指南

1. 為什麼要關注前端演進史？

1.1 從「電子海報」到「桌面應用程式」

1.2 一個生活的比喻：蓋房子

2. 第一階段：靜態網頁與「切圖」（2000s）

2.1 這個時代是什麼樣的？

2.2 「切圖」是什麼？

3. 第二階段：jQuery 時代 - 「手動搬磚」（2010s）

3.1 為什麼需要 jQuery？

3.2 jQuery 的思路：親手改頁面

3.3 行動裝置普及：回應式設計的出現

4. 第三階段：從「手動搬磚」到「資料驅動」（Vue/React）

4.1 為什麼需要新框架？

4.2 Vue/React 的思路：宣告式 UI

4.3 元件化：像搭樂高一樣寫頁面

4.4 SPA：單頁應用程式的誕生

5. 渲染策略：從 CSR 到 SSR/SSG

6. 第四階段：工程化與建構工具（2015s-2020s）

6.1 為什麼需要「工程化」？

6.2 建構工具：Webpack → Vite

7. 主流框架對比

7.1 四大框架對比

7.2 Vue：漸進式框架

7.3 React：UI 函式庫

7.4 Svelte：編譯時框架

7.5 Angular：完整平臺

8. 總結：演進的本質

8.1 效率：從手動到自動

8.2 規模：從個人到團隊

9. 學習路線圖

9.1 如果你是零基礎

9.2 如果你有基礎

10. 你現在應該能識別的程式碼

名詞速查表