Chapter 07

為什麼使用框架？以及近年常見的最新主流框架

當網站變成多人協作、需要路由、狀態管理、伺服器整合、SEO、部署與測試時， 只靠零散的原生語法往往很快就失控。框架的角色，就是把這些重複問題整理成一套結構與慣例；但在往下看之前，必須先把 Web server、Runtime、Library、Toolkit 與 Framework 的層次分清楚。

框架是什麼？它和 Library、Runtime、Web server 有什麼不同？

若先用教學上最容易建立整體概念的「由外到內」階層來看，可以先理解成： Web server（入口層）→ Runtime（執行層）→ Framework（應用結構層）→ Library（功能輔助層）。 這不是唯一的技術依賴圖，但對初學者最容易建立分層感。

flowchart LR A[Web server 入口層] --> B[Runtime 執行層] B --> C[Framework 應用結構層] C --> D[Library 功能輔助層] C --> E[Toolkit / UI framework 介面工具層]
先看圖，再看表： 架構圖幫你先抓整體層次；表格則補上每一層的角色與例子。兩者一起看，比只背名詞更容易建立空間感。
層次 名詞 角色 例子
入口層 Web server 接收 HTTP request、回應資源，或把請求轉送到後端應用服務 Nginx、Apache、Node 內建 http server、Python http.server
執行層 Runtime 讓程式碼可以執行的環境 Node.js（JavaScript Runtime）、Python、Java JVM
應用結構層 Framework 提供整體結構、規則與慣例，由它主導較多流程 Express、Angular、Django、NestJS、Next.js
功能輔助層 Library 提供函式或元件，由你主動呼叫 jQuery、Axios、Lodash、D3.js、Alpine.js
重要觀念： 這張表採用的是「教學上的理解順序」，也就是先看入口與執行，再看應用結構與功能輔助。
其中 Node.js 是 Runtime，不是 Framework；Express、NestJS、Next.js 才是建立在 Node.js 之上的框架或相關工具。
如果你原本熟悉 Apache / Nginx，可以把這理解成：Web server 管入口，Runtime 管執行，Framework 管應用結構，而 Library 則是在應用裡幫你處理特定功能。

如果只看應用程式內部：Framework、Toolkit、Library 到底差在哪裡？

如果把 Web server 與 Runtime 先放到外層，再只看應用程式內部，就可以再用「由大到小」的方式理解成： Framework → Toolkit / UI framework → Library。

類型 誰控制流程？ 主要價值 例子
Framework 框架提供整體結構與生命週期 幫你管理路由、模組、資料流與專案慣例 Angular、Next.js、NestJS、Django
Toolkit / UI framework 多半仍由你主導畫面流程 提供現成元件、樣式與互動模式 Bootstrap、Tailwind UI、Alpine.js（偏輕量互動）
Library 通常由你的程式主動呼叫 把常見功能封裝好，讓你少寫重複程式 jQuery、Axios、Lodash、D3.js
容易混淆的點： React 常被稱為 UI library，但實務上常和 Vue、Angular 一起放在前端框架生態討論； Bootstrap 則更接近 UI toolkit / CSS framework，而不是通用 JavaScript library。 如果你想看 JavaScript 從歷史演進到前後端整體架構的完整地圖，可以接著看 第 08 章；如果你想看經典 library 的代表案例，則可再看 第 09 章：jQuery 詳解。

如果你是從傳統 HTTP server 管理者角度切入

你熟悉的傳統世界 角色 Node.js / Framework 世界的對應 該怎麼理解
Apache / Nginx VirtualHost 網站入口 Nginx / Apache 依然可以是入口 框架化之後，入口層並沒有消失。
PHP-FPM / uWSGI 執行應用程式 Node.js Process / Python Process 這一層更接近 Runtime，而不是 Framework。
Laravel / Symfony 應用框架 Express / NestJS / FastAPI / Django 這一層負責路由、驗證、模組與商業邏輯。
Rewrite / ProxyPass 路徑轉送 Nginx 反向代理 + Framework Route 一部分在 Web server，一部分在應用框架。
最容易卡住的地方： 很多人會把 Node.js 誤當成 Nginx / Apache 的替代品。其實更精確的理解是： Nginx / Apache 仍然可以在前面接請求，而 Node.js 是後面讓 JavaScript 應用跑起來的 Runtime。

傳統 Web server 與框架式 Web service 的差別

flowchart LR Client[Browser / App] --> Entry[Nginx / Apache] Entry --> Static[直接回應靜態檔] Entry --> Proxy[反向代理動態請求] Proxy --> Runtime[Node.js / Python Runtime] Runtime --> Service[Express / FastAPI / Django / NestJS] Service --> DB[(Database)]
面向 傳統 Web server 框架式 Web service
主要角色 接請求、回靜態檔、反向代理 處理商業邏輯、API、資料驗證、模組化
路由能力 通常偏基礎，或以設定檔為主 通常提供結構化路由、middleware、controller
動態資料 能做，但管理起來較原始 更適合整合資料庫、認證、權限與 API 文件
部署位置 常位於最前面，作為入口或 reverse proxy 常在 Runtime 裡執行，作為真正處理業務的服務
常見組合 Nginx / Apache + Node.js Runtime + Express / NestJS，或 Nginx / Apache + Python + FastAPI / Django
教學上最重要的觀念： 「傳統 Web server」與「框架式 Web service」不是二選一，而是經常一起出現：前者負責入口與傳送，後者負責應用邏輯。

Example：Nginx 反向代理到 Express，分工到底在哪裡？

把入口層與應用層拆開看

這個例子最適合傳統 HTTP server 管理者，因為它直接把 Nginx 設定與 Express 應用放在一起比較。

# Nginx：負責入口與反向代理
server {
  listen 80;
  server_name demo.school.tw;

  location / {
    root /var/www/site;
    index index.html;
  }

  location /api/ {
    proxy_pass http://127.0.0.1:3000;
  }
}

// Express：負責應用程式邏輯
const express = require("express");
const app = express();

app.get("/api/status", (req, res) => {
  res.json({ service: "ok", owner: "framework service" });
});

app.listen(3000);
  1. 瀏覽器先連到 Nginx。
  2. Nginx 發現 /api/ 開頭的請求，轉送到 127.0.0.1:3000。
  3. Node.js Runtime 執行中的 Express 應用接手處理。
  4. Express 根據 app.get("/api/status") 回傳 JSON。
  • Nginx 沒有消失，它仍然可以是網站入口、TLS 終結點與靜態檔伺服器。
  • Node.js 是 Express 所依附的 Runtime，負責把這個應用跑起來。
  • Express 讓你不用在 server 程式裡手動拆每個 URL，而是以更高層次的路由 API 來寫。

同一個 /api/status，在原生 Node、Express、NestJS 各寫在哪裡？

原生 Node.js

if (req.url === "/api/status") {
  res.end("ok");
}

你要自己處理 request / response 細節，最能看見底層。

Express

app.get("/api/status", (req, res) => {
  res.json({ service: "ok" });
});

用較少程式碼宣告路由，是很多 Node.js Web 專案的起點。

NestJS

@Controller("api")
export class StatusController {
  @Get("status")
  getStatus() {
    return { service: "ok" };
  }
}

再往上走一步，把路由、模組與服務分層，適合大型團隊與大型後端。

理解順序： 原生 Node.js 幫你看見底層；Express 幫你減少重複勞務；NestJS 幫你在大型專案中維持架構秩序。

如果不用框架，通常會先卡在哪裡？

路由越來越多

一開始只有 1、2 條路由沒問題，但需求一多，if / else 很快會失控。

重複工作變多

參數驗證、錯誤格式、回應格式、權限檢查，常常每支 API 都要重寫一次。

團隊協作混亂

當檔案、模組、命名與資料流沒有慣例時，專案規模一大就很難維護。

這就是框架存在的動機： 框架不是因為「比較潮」，而是因為當專案規模變大，重複勞務與結構混亂會比語法本身更快拖慢開發。

為什麼要使用框架？

提升效率

常見問題已經有現成結構可用，例如路由、元件、表單、驗證、狀態管理。

統一架構

團隊成員能用相同方式命名、拆模組、放頁面與管理資料流。

方便整合

框架通常能和 SSR、資料庫、API、測試工具與部署平台更容易接軌。

不是所有專案都要框架： 如果是簡單靜態頁面，純 HTML / CSS / JavaScript 就很夠用。 但如果要做大型站點、互動儀表板、後端 API、全端專案，框架通常會大幅降低混亂程度。

近年常見的主流框架與定位（截至 2026 年前後）

分類 代表工具 定位 常見應用
前端 UI / Framework React、Vue、Angular、Svelte、Qwik 專注畫面與互動邏輯，建立元件化前端 SPA、互動後台、產品介面
Meta / Full-stack Next.js、Nuxt、Remix、SvelteKit、Astro 整合頁面路由、SSR/SSG、API 與部署策略 內容網站、SEO 專案、全端應用
後端 Framework NestJS、FastAPI、Django、Laravel、Spring Boot 處理 API、資料庫、驗證、權限與伺服器架構 後台服務、API 平台、企業系統

前端代表

React 生態成熟；Vue 易學且靈活；Angular 結構完整；Svelte 與 Qwik 強調輕量與效能。

全端代表

Next.js 與 Nuxt 是全端主流；Astro 特別適合內容網站；Remix 與 SvelteKit 著重 Web fundamentals 與開發體驗。

Example 1：React 元件寫法與預期畫面

元件化思維

框架常把 UI 拆成可重用元件。這個例子只是一張卡片，但已經能看出元件思維。

function CourseCard({ title, level }) {
  return (
    <article className="card">
      <h2>{title}</h2>
      <p>難度：{level}</p>
    </article>
  );
}

HTTP 進階

難度：中階

  • 框架把 UI 切成可重用元件，之後同樣樣式只要改資料就能重複使用。
  • 這比手動拼很多重複 HTML 更容易維護。
  • 當畫面越複雜，元件化的好處越明顯。

Example 2：FastAPI / Backend Route 的思維

後端框架幫你更有結構地處理 API

後端框架通常讓路由、驗證、型別與文件生成更有系統。

from fastapi import FastAPI

app = FastAPI()

@app.get("/api/status")
def get_status():
    return {"service": "ok", "version": "1.0"}
GET /api/status 
{
  "service": "ok",
  "version": "1.0"
}
  • 框架把「路徑對應到函式」這件事寫得更清楚。
  • 很多後端框架還會幫你處理參數驗證、文件與錯誤格式。
  • 這就是為什麼大型 API 專案很少從零手寫每一層細節。

框架怎麼選？

考量面 問題
學習門檻 團隊成員是否熟悉這個語言與生態？
SEO 與內容導向 是否需要 SSR / SSG？內容是否比互動更重要？
互動複雜度 畫面狀態是否很多？是否需要元件化與狀態管理？
後端需求 是否要同時做 API、權限、資料庫整合？
部署與效能 是否要支援靜態部署、Edge、Serverless 或企業級環境？

Summary：本章結論

  • 框架是為了處理大型專案中的重複問題與結構問題，不是為了取代 Web 的底層原理。
  • Library 常是你主動呼叫；Framework 更像是提供一套規範與工作流程。
  • 如果你熟悉 Apache / Nginx + PHP-FPM 的思維，可以用同樣的分層方式去理解 Node.js Runtime 與 Express / NestJS 這類框架。
  • 真正推動你使用框架的原因，通常不是語法比較短，而是路由、驗證、模組與團隊協作在規模變大後需要一致的結構。
  • 若要把 library、toolkit、runtime 與前後端流程放在同一張地圖理解，可再讀第 08 章的 JavaScript 全貌。