## 為什麼有框架？
### 背景
首先要了解過往開發軟體所碰上的挑戰，來看看一個常見的例子：**待辦事項程式**。

過往應用程式要能讓使用者執行諸如渲染事項列表，添加新任務和刪除任務之類的操作；還要能可靠地追蹤、更新程式所依賴的資料，此這些資料稱為**狀態（state）**。

每個目標分開來看，理論上都很簡單：我們能遍歷需要渲染的資料、建立新的工作物件、還能用標識符來查詢、編輯或刪除工作。

然而，當我們要求程式，讓用戶在瀏覽器完成這一切的話，麻煩就來了。問題在於：更動狀態時，也同時需要更動 UI 的顯示。

### 基本概念
以 Vue 為例，因為有 Vue，我們再也不用自己寫針對 UI 呈現的函式；整個框架會幫我們用最有效率的方法完成這件事。

我們只要告訴 Vue 整個排版要怎麼排就好。熟悉 Vue 的開發者，也可以盡快參與我們的專案、搞清楚整個專案到底怎麼做的。不過並不是只有 Vue 這樣：**使用框架本身，就可以提高團隊與個人的工作效率**。

要在原生 JavaScript 做類似的事是可以的。樣板文字就能在編寫 HTML 字串的同時，也表示最終元素的外觀。

如果只是待辦事項，這可能還是一個方便的做法，但是對於管理成千上萬條數據記錄、並且要在用戶界面中呈現盡可能多元素的大型應用程式而言，這樣子是很難維護的。

## 框架給我們的其他東西
讓我們看看框架賦予的其他優勢。正如之前提，你可以透過原生 JavaScript 實現框架，但是使用框架可以消除自行解決這些問題所需要的認知負擔。

### 工具
本模塊提到的幾個框架，背後都有著龐大而活躍的社群；這些社群形成了各種生態圈、並提供能增進開發體驗的工具：像是確保功能正常的測試、或著維持程式一致性的 linting。

備註： 如果對這方面的概念有興趣，請看看 [Client-side tooling overview](https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Client-side_tools/Overview)。

### 切分
大多數框架鼓勵開發者把介面的各部份，封裝成各種組件（components）：也就是一個個可維護、可互通、還可重用的程式碼塊（chunks of code）。與該組件相關連的程式，可獨立為一個、或數個獨立的程式。

在原生 JavaScript 裡面要這麼做的話，開發者就必須靠自己的慣例，才能在高效、可擴展的情況下，達成這個目標。但大多數的 JavaScript 開發者，最後會讓 UI 相關的所有程式，都分散在整個文件中。

### 路由
web 的其中一個重要功能，就是頁面之間的導航：畢竟它就是相互連接文件的網路。在你點選網站上的連結時，瀏覽器會與伺服器溝通、並獲取新內容以便顯示給你看。

也因為這樣，地址欄中的 URL 就會更改。你可以保存這個新的 URL 並稍後回來、或與其他人分享該 URL，以便他們輕鬆地找到同一個頁面。你的瀏覽器會記住這個導航歷史記錄，也能在頁面之間來回導航。這就叫**伺服器端路由（server-side routing）**。

現代的網路應用程式通常不獲取和渲染新的 HTML 文件：它們通常載入單個 HTML Shell，並不斷更新其中的 DOM 同時，不導航用戶到新地址（這被稱為**單頁應用、single page apps、SPA**）。每個新的虛擬網頁通常稱為 視圖（view），一般來說也不執行路由。

在 SPA 複雜到一定的程度、也有渲染出足夠獨特的視圖時，給應用程式導入路由功能，就變得很重要：人們習慣在應用程式中，透過連結導航到特定頁面，在導航歷史記錄中前進和後退等，而當這些標準的 Web 功能被破壞時，他們的體驗也會受到影響。如果導航功能以用戶端程式提供，這就叫做**用戶端路由（client-side routing）**。

你可以透過原生 JavaScript 實做路由功能。但比較活躍的框架都有相對應的函式庫，讓路由功能在開發過程中更加直觀。

參考資料：[Introduction to client-side frameworks](https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Frameworks_libraries/Introduction)