JavaScript框架的前世今生
值得和我水平相当的初学者前去阅读
这篇文章写于2017年的后半年,但中文网上仍没有相对应的文章,可以看出中文社区信息的延迟性
引自:
https://ithelp.ithome.com.tw/articles/10194844
https://ithelp.ithome.com.tw/articles/10195050
https://ithelp.ithome.com.tw/articles/10195239
我认为:这三篇文章中,没有一句话,一个字,一个标点是多余的,
摘抄没有意义,我引用了前两篇文章90%以上的内容,第三篇文章还请大家自己去品读
结论:框架的出现,是为了更好的Web开发体验和Web开发效率
以操作 DOM 為主：
像大家都很熟悉的 jQuery、 YUI (我們懷念它)、或是早期的 PrototypeJS (不是 JavaScript 原生的那個 prototype)、Dojo 等都屬於這一類型。此類工具主打的就是對 DOM 的操作變得更簡便。 優點就是上手容易，操作直覺，我拿到 DOM 之後就直接對它做事。 早期大約十幾年前的主流工具庫多屬於這種類型。
整合 Web UI 、處理圖形化介面為主：
主要想解決的目標的是把包裝好的各種圖形化介面直接拿來使用。
像 Bootstrap、jQuery UI、Kendo UI 等這種已經幫你把幾個常用的圖形化介面都封裝好，開發者只需要準備好容器的節點，幾乎只要一初始化就可以直接使用。
網頁模版引擎：
我們只要把資料 (JSON) 準備好，然後送進模板，就會生成對應的 HTML。 就整體架構面來說，這樣拆分的結果更方便我們透過 JavaScript 來建構較具規模的應用程式，同時專案的可讀性與可維護性也大大增強。
前端應用架構整合：
現在我們把時間軸稍微往後推一些，時間來到了 2010 年前後。 由於過去不少前輩的努力，這個時候的 JavaScript 早就已經不是那個只能拿來寫寫特效啊，跑馬燈，或是簡單驗證的東西了。
此時開發者們發現，當網站的應用程式越來越複雜的時候，即使我們已經把 HTML、CSS 以及 JavaScrpipt 都拆開維護了，在大型系統的開發架構上仍然還是覺得少了些什麼。
於是在這個時期，各種從其他語言借鑒的特性大量被實作，MVC、MVP、MVVM ...等等框架在前端的領域可以說是蓬勃發展。
比較早期像是 Backbone.js，
真正集大成可以算是 EmberJS、AngularJS (v1) 以及 Knockout.js 時期，這幾套前端框架各有所長，但最驚豔的部分是 View 和 Model 可以直接來做 binding，這在過去很習慣直接以操作 DOM 為開發手段的我們，其實是個相當大的突破。 除此之外，像是 directive、template 以及 routing 的整合，也為開發者帶來相當大的便利
然而這類「大而全」的工具在當時的時空背景下，還要顧慮到對舊環境的支援，所帶來的代價就是效能問題。
於是，後來的故事相信大家都知道了，React 的崛起，Angular2 捲土重來，然後是 Vue 的三分天下
其他：
除了前面介紹的框架/工具，另外也還有其他針對特殊目的所開發的：
單元測試：
像 Jasmine、Mocha、QUnit 等就是專門作為測試使用的工具。
處理視覺化為主 (主要是處理 SVG 或 Canvas)：
比較知名的像是 D3.js、p5.js 以及 Highcharts 都是專門用來處理資料圖表使用。
webGL 系則有老牌的 Three.js，最近超火熱的 PIXI.js 也都屬於此類的工具。
純工具庫：
單純用來作為提供 JavaScript 的增強工具庫，像是 Underscore、Lodash 等。
第二部分:
現在人們談論到 SPA (Single Page Application, 單頁式應用) 可能都會認為是在 2007 年 iPhone 推出之後，Mobile Web 日漸增長之後才開始蓬勃發展的。
事實上，SPA 的崛起可能比起你我的想像還要早得許多。
最早期的網頁幾乎都是以靜態網頁為主，所有資料直接從 Server 端輸出，幾乎不需要做運算，就是單純的 HTML。就算有後端語言，最多也就是負責表單的處理。 後來過了幾年，有了「動態網頁程式」的語言 (如 PHP、ASP 等) 開始由後端程式語言負責處理頁面邏輯，加上資料庫系統的成熟，使得原本無法紀錄狀態的網頁，可以利用資料庫來記錄狀態及資料
時間來到 2004 年。 幾乎所有在介紹 Ajax 的文章都會提到這個產品。
沒錯，就是由 Google 所推出的 Gmail。
除了 Ajax 以外，當時想要在網頁上製作應用程式還有另外一派，那就是由 Macromedia 所開發的 Flash (後來被 Adobe 買下) 以及微軟的 Sliverlight。
傳統多頁式的網站與單頁式網站最大的差別就是省下了換頁的成本，不需要重新載入網頁，操作的回饋更即時。 取而代之的是透過 Ajax 取得需要被更新的資料，然後透過 JavaScript 將網頁的內容替換。 但同時也遇到了新的挑戰，首先面臨的問題就是使用者的習慣、狀態的管理，以及 SEO 的考量。
先前提過，長久以來使用者「被教育」操作網頁建置的系統時，要回到前一個步驟，一定會去按「上一頁」，但網頁是用 Ajax 更新的資料，哪裡來的上一頁與下一頁可以給使用者切換。
當然早期前輩們也想過這個問題，想要動 URL 又不能換頁，只好改 URL Hash。
還好後來 HTML5 之後，新的規範提供了 History API，可以透過 pushState()、replaceState() 的方式更新 URL，以及 history.go(); 、 history.back(); 來切換頁面的上下頁路徑，同時也提供了 state 物件來讓開發者存取每一頁的狀態。
而這種搭配 pushState 的方式，甚至有人把它與 Ajax 合併，合稱為「Pjax」。
從桌面應用到行動裝置(SPA做的是应用程序,而不是动态的网页)
所以說除了技術面以外，開發 SPA 的另一個重點則是開發者的思維，否則技術再先進，做出來的東西依然是網頁，那個樣子怎麼看都不會是應用程式。
其實現代主流的前端框架，早一點的像 Backbone、AngularJS，到後來的 React、Vue 也有提供 SPA 相關的解決方案。 然而了解哪些場景該用傳統後端，哪些該用 SPA 來開發，則是 Web 開發人員的未來需要面對的另一個課題。
MV* 框架的出現與開發思維的轉變
網頁開發的思維從早期的「義大利麵式程式碼」(Spaghetti code) 把所有的東西通通往 HTML 頁面塞，到了後來有人提倡「關注點分離」，將 HTML、CSS 及 JavaScript 拆開來，這是表現層級上的關注點分離。
然而，當專案的架構越來越大，人們開始把「關注點」從表現層移到了架構層面。 於是，分成了「資料層」、「表現層」以及「邏輯層」，也就是所謂的 MVC 概念
當瀏覽器開啟 View 的時候，View 會向 Controller 提出請求。 Controller 處理完商業邏輯的部分之後，要求 Model 端改變狀態，然後 Model 再將資料反映到 View 上。
以 Backbone 來說，使用者可以透過 DOM 事件對 View 發送指令，再由 View 要求 Model 改變狀態。 但同時使用者也可以透過操作 URL 來對 Controller 做操作，再由 Controller 去改變 View。
這個時候你會發現前端 MVC 與後端 MVC 有著一個很大的差異： 前端的 MVC 著重在事件流程，而後端的重點在於資料流。
後端 MVC 的 View 就相當於是前端的全部了：
當前後端分離後，後端幾乎不需要去處理 View 的部分。相對地，後端的 V 變成前端的 M，那些原本放在後端處理畫面、邏輯的部分，其實很大程度地往前端移動。
於是前端框架慢慢發展成 MVVM 模式。
像比較早期的 Ember、Angular 採用資料的雙向綁定作法，當 View 操作 (DOM event) 變動，透過 ViewModel 去操作 Model (JavaScript Object)，反過來也是。
後來的 React、Vue 也都延續採用 Single Source of Truth (SSOT) 的準則，使得資料流更容易被追蹤，架構也更好維護。
一般來說，後端的 Controller 是指 URL 與 Http Method 的部分，而前端可以透過 URL 操作 (hashtag / pushState) 以及 DOM Event 去對 View 做操作。 所以通常前端框架不會直接稱自己是 MVC 框架，而是被稱作 MV* (MVC/MVP/MVVM...) 的框架。
今天講了滿多與 SPA 相關的東西，也是藉此與各位聊聊網頁應用的架構，是如何從傳統的後端為主逐漸發展至 SPA (但目前也未必是主流)，以及它所延伸出的問題。
