前端框架第 0 課：學習框架前該知道的事

8 min readJul 11, 2021

前端框架的選擇一直是很多新手（包括我）的大哉問，我當初是因為公司在用 React 就也只能先寫 React 了，前陣子因緣際會開始碰了一下 Angular ，進而啟發我對於「前端框架」進行更多思考，像是「框架」到底是指什麼？什麼東西可以被稱為「框架」？為何前端需要去使用它？不用它會怎麼樣？聽說 Vue3 很猛，我該去學嗎？等等的問題。

而這篇文章就算是我在解決上述一些問題的思考，也是我認為在我們跳下去學一個框架之前，該先知道的一些基本觀念。

簡短講一下網頁發展史

技術發展日新月異，但其實技術的本質都是在「解決問題」。

藉由理解技術的脈絡，我相信對於理解眼前的技術跟想像未來的發展都是很有幫助的。

1990 年代：網頁誕生

1990年12月20日 Tim Berners Lee 寫出了第一個網站並設計了 World Wide Web
這時期以靜態網頁為主，頂多有一些動態的選單和圖片特效

2000 年代：Web 2.0 ＋ Ajax

2004 年 Web 2.0 的誕生，使得網頁互動性開始提升，像 Facebook (2004)、Youtube (2005) 都是在這時期出來的
Ajax 非同步的應用，是讓網頁透過 JS 而不是瀏覽器來發送請求，因而不用重新載入來更新資料

2010 年代：網頁應用程式（Web Application ）概念出現

從這時候開始，Web 的複雜度跟互動性已經大幅提升，逐漸能做到原先桌面應用程式 ( Desktop Application）才能做到的事

為了因應這種高互動性的網站都會需要有的一些基本處理，前端框架就此誕生。

Angular 1.0 (2010)
React (2013)
Vue (2014)

（對更詳細的演進史有興趣的話會在底下附上參考連結）

具體來說，前端框架幫我們處理了什麼？

ㄧ、元件 Components

可複用、各自獨立的 UI，如 Button

單靠純原生的 HTML, CSS, JS 要去做到 Component 的概念很麻煩，而藉由框架，我們可以很快地去撰寫 Component，幫助我們複用程式碼、加速開發也提升開發者體驗
而一個 Components 會包含 跨層溝通的方式 ( External Props )、可管理的內部狀態 ( Internal States ) 和 使用者事件 ( Listen to browser events )

二、狀態管理 State Management

管理資料和使用者操作事件的互動流程

網頁中的狀態表示了你在當前網站所處的階段，像是會員系統會有訪客和會員兩種狀態，而訊息也會有已讀跟未讀兩種狀態等等，因應網站的複雜度，你在整個網頁應用程式中，也會有很多的狀態需要去管理

大致上會有三種情形：

元件本身的狀態（Component-Level State)：狀態只在單一元件裡被管理、使用，像是 React 的 useState
元間之間的狀態（Share State Across Components）：資料或狀態在元件之間傳遞，並且會同時會影響到多個元件的情形，像是 React 的 useContext 或是 Props
整個網頁的狀態（Global State）：在網頁中任何地方都可以被管理、取用的狀態，在 React 裡通常會搭配 Redux 來幫忙管理。

三、生命週期 Life Cycle

框架在瀏覽器上運作的流程，幫我們處理 DOM 和瀏覽器渲染機制

我們寫的 Components 要實際出現在瀏覽器上時，其實經歷了這個過程：Mounting → Updating → Unmounting

Mounting：當 component 的 instance 被建立，並顯示在DOM上
Updating：狀態改變時，重新渲染DOM(re-render)
Unmounting：當 component 將要從DOM被移除的時候

各框架之間都是遵循著這樣的流程，但觸發 re-render 的方式則會因應底層的實作邏輯而更有不同，這關乎於框架如何去對應使用者互動事件和狀態的改變。針對框架的效能優化也很大部分是在處理 re-render 的機制。

四、路由 Routing (Client-Side)

在前端處理頁面之間的導航、切換

以往 Server 直接吐 HTML 給前端的作法

在你點選網站上的連結時，瀏覽器會與伺服器溝通、並獲取新內容以便顯示給你看
而取得新內容後，地址欄中的 URL 就會更改。

前端框架的作法

Server 只回一個 HTML 作為根節點，之後的變動都是在更新它的 DOM
因為頁面之間的切換不再透過瀏覽器，而是在前端這邊透過 JS 來動態改變，因此路由也得由前端來實行了
React 需要透過 React-Router 來輔助實行，而 Angular 則是有自己內建的 Routing 系統

前端框架帶來的好處

上面講了那麼多框架應用到的概念後，稍微來梳理一下這些概念所能達成的好處跟效果。

一、更好的開發者體驗

前端框架，如同很多技術的變革一樣，本身並沒有給 JavaScript 提供新功能，而只是提供了讓我們能更容易地寫網站的方式。

撰寫可複用的獨立元件，大大地增加程式的可讀性和可維護性。以往原生 JS 試圖重複建立新 DOM 元素的方法，很難一眼理解，可以試著去比較 To-Do List 在使用框架前後的程式碼就能知道差別了
使用框架本身，就可以提高團隊與個人的工作效率，有了框架的知識架構後，很多規範就都會框架級別定義出來，因而大大地減輕了理解專案的認知負擔。

二、各種好用工具和生態系

一項技術崛起後，人們會在這門的基礎上繼續開發出很多好用的工具，並且會有許多嶄新的可能性和原先沒想到的問題，風氣帶起來後，喜歡使用這門技術的人們就會逐漸形成「社群」。

社群會為這門技術建立生態系，開發者們會因應需求開發出各式各樣的工具，增進日後的開發體驗和效率。

因此，技術本身很重要，但要讓人們願意使用技術也是很重要的。

（技術也是要懂得行銷，行銷成功有了社群才能發揚光大，畢竟個人或一小群人的能力真的有限）

講了這麼多，到底該如何選擇框架？

小孩子才做選擇，大人解決問題

理解上述概念後，我們能知道各大框架都是在解決什麼樣的問題，並有共通的實作概念，只是底層機制不太一樣後，學習別的框架就只是熟悉新的語法和實作機制而已，背後其實共享著的是同樣一套解決問題的思考迴路。

因此比起選擇，我們更該在乎的是：

更熟悉 JavaScript
理解上述所提到的各個概念在框架中是如何運作跟實作的

如果真的要選一個框架的話，建議就是 React、Vue 和 Angular 的文件都翻翻看，Tutorial 寫一寫，感受一下你比較喜歡哪個框架。

其實，沒有一個框架能讓你寫一輩子的

學習框架的過程中要一直提醒自己不要成為「框架工程師」，意思是不要只是很熟悉使用框架這個「工具」，而忽略了框架一開始會出現是來解決什麼樣的問題，以及後續的技術變革又是來解決框架現行遇到的什麼問題。

像是最近 Server-Side Rendering 的概念就很紅，未來也一定會再有許多變革的。

最後，觀念釐清一下：框架(Framework) vs 函式庫(Library)

雖然我們很習慣講「三大框架」，但其實 React 只能說是 Library，因為作為一個框架來說，他幫你處理的事情還太少了。

框架 (Framework)：就如同上述所說，會是個功能完善的全家桶，並且對於實作方式有較嚴格的要求，像是 Router, FetchAPI 等操作都會有規定。

Angular 就完美符合一個框架的標準，因為它把所有東西都整合成官方 API 了。

函式庫 (Library)：以 React 為例，它其實只處理了 Life Cycle，其他都需要第三方 Library 幫忙整合，像是 renderer 要加 react-dom，而 router 要用 react-router 等。

結語

其實還有很多東西沒有涵蓋到，但如同一開始所說，這篇文章的目的只是讓大家在學習框架前，先掌握一些架構，理解這技術怎麼來的，為什麼該用，用了能解決什麼問題，而不是盲目地就跳下去學，像我一開始直接跳下去 Angular 的文件海洋中時，真的是覺得自己快溺死了，但如果能先掌握對框架的基本架構，相信就不會有如在汪洋大海那般無助，至少能看見遠方有座島嶼了🏝。

最後也謝謝看到這邊的大家，這是我第一次寫技術文章，其實想開始寫很久了，畢竟自己平常也受益於許多願意分享的前輩，也要多虧莫力全 Kyle Mo 和 Ian-Lai 的鼓勵，現在終於也跨出第一步啦！

如果覺得有哪裡不清楚的地方請留言告訴我，希望這次分享的內容對於大家是有幫助的，那麼就下次再見啦～

喜歡的話歡迎幫我拍手，拍手最多可以拍50下，依據你覺得有幫助的程度幫我拍手就好，這也可以成為讓我調整的依據🙌

References

演進史相關連結：