2-key-value.md

May 22, 2025 · View on GitHub

11.2 從 Key-Value 對應出發：前端框架的語意演化

在上一節（11.1），我們使用 jQuery 手動將 JSON 資料一筆筆插入 HTML。這個過程看似簡單，卻揭露了語言層面的限制 —— 每一次資料變化，都需要人工轉譯為畫面。

從這個痛點出發，我們才真正理解框架的意義：不是為了節省程式碼，而是為了讓資料與畫面之間，能有一個穩定的語意映射流程。

REST API 提供的是「資料語意接口」，而前端框架則是這個語意接口的「畫面翻譯層」。Backbone.js 就是我們從手動語言轉向語意架構的第一步。

當資料開始變得動態，HTML 也不再只是靜態頁面，它變成了一種語意映射器。你不是在寫畫面，而是在定義資料該如何呈現。

上一節我們手動將 REST API 回傳的 JSON 逐一渲染到畫面上，這在初期是可以接受的，但隨著資料變多、畫面變複雜，我們需要一種更穩定、更可維護的語言邏輯。而這個邏輯的核心，就是從最基本的 Key-Value 對應 開始。

JSON 的資料格式本質上是一種 Key-Value 結構，例如：

{ "name": "jollen" }

這代表「name 是變數，jollen 是值」。如果今天我們希望將這樣的資料渲染到 HTML 畫面上，最直覺的方式會是這樣：

<p>$name</p>

然後資料如下：

[
  { "name": "Peter" },
  { "name": "Paul" },
  { "name": "John" }
]

我們希望畫面變成：

<p>Peter</p>
<p>Paul</p>
<p>John</p>

這種「資料對映畫面」的行為，就是前端框架存在的原因。

手動撰寫 DOM 不只是麻煩，它容易出錯、難以維護、難以重構。而 UI 框架的出現，就是為了解決這個問題：把資料與畫面中間的對應邏輯抽象出來，讓它成為程式的一部分。

這就是我們為什麼需要 Backbone.js。

你可能聽過很多名字：React、Vue、Angular、Svelte⋯⋯這些都是 UI 框架。但它們其實不是「工具」，而是「語意設計的策略」。

但對初學者而言，這些都太快了。

我們不是為了「用」框架，而是為了「理解」框架——為什麼我們需要一個能把 Key 對應到畫面的架構？為什麼不能手刻？這正是 Backbone.js 所扮演的角色：它是一個讓你學會 MVC 架構與語意映射邏輯的起手式。

MVC 模式你可能已熟悉：Model 是資料、View 是畫面、Controller 是邏輯。但在實作 UI 時，這三者常常糾纏在一起。這時，MVVM（Model-View-ViewModel）模式登場了。

在 MVVM 裡：

也就是說：你不再需要 Controller 手動「搬運資料」，ViewModel 會自動根據資料變化，更新畫面。

ViewModel 就像是語意中介層，它的任務不是邏輯處理，而是資料的語意對應與映射。

這也讓 UI 設計師能單純專注在設計畫面，不需操心資料結構。這種分離，被稱為 Code Ignorance：讓設計不用寫程式，讓邏輯不污染畫面。

Backbone.js 是一套早期的前端框架，它的特點不在於「功能強」，而在於「結構清晰」。它幾乎是手工版的 MVC，每個元件都要你明確建立與綁定。

這看起來很麻煩，但它能讓你真正看見 MVC 的骨架：

這樣的設計，是為了學習，而不是為了高效開發。Backbone 就像是語意框架的透明教科書，它讓你看見 Key-Value 怎麼變成畫面，怎麼更新，怎麼消失。

我們不急著跑，先學會怎麼一步一步走，這才是成為 Fullstack Developer 的節奏。

從下一章開始，我們就將以 Backbone.js 開始建立我們的第一個語意驅動 UI —— NoChat 的留言畫面。