一、前言

關(guān)于 JS 框架部分能聊的內(nèi)容比較多，我相信大家對(duì)某個(gè)框架的使用、原理等知識(shí)是比較容易找到資料來學(xué)習(xí)的，鑒于此這部分內(nèi)容將會(huì)從另一個(gè)視角出發(fā)：通過回顧 JS 框架的發(fā)展歷程，和大家一起探討框架的本質(zhì)以及 JS 框架不斷變化背后的驅(qū)動(dòng)力。正所謂「鑒往知來」，希望大家能對(duì) JS 框架有更全面的認(rèn)知，能夠把握變化背后不變的邏輯，更好的應(yīng)對(duì)未來新的變化。

二、什么是框架

在講清楚一件事情之前，我們需要先準(zhǔn)確定義它，這一部分我們先定義清楚什么是框架以及什么是 JS 框架。

先看一個(gè)通用意義上「框架」的的定義：

 框架（framework）是一個(gè)框子——指其約束性，也是一個(gè)架子——指其支撐性。是一個(gè)基本概念上的結(jié)構(gòu)，用于去解決或者處理復(fù)雜的問題。

個(gè)人非常喜歡這個(gè)定義，簡(jiǎn)潔而準(zhǔn)確，框架的核心就是「約束性」和「支撐性」。

如何理解「約束性」

框架是解決復(fù)雜領(lǐng)域問題的系統(tǒng)性方法，對(duì)于復(fù)雜問題而言，往往缺失「銀彈」，大家看問題的角度會(huì)有差異，每個(gè)框架背后都有自己的理念，當(dāng)你選擇某個(gè)框架就需要遵循它的邏輯和規(guī)則，在規(guī)則之內(nèi)解決問題，這是「約束性」。

如何理解「支撐性」

復(fù)雜問題通?？梢圆鸾獬梢幌盗行栴}，問題的整體解法則是如何解決它們中的所有或者部分，框架的「支撐性」體現(xiàn)在它提供了問題的定義和一系列解決問題的方法，基于它能夠?qū)⑨槍?duì)各個(gè)子問題的解法更加有序的組織起來，最終形成整體的解法，「支撐性」即有序組織。

如何定義 JS 框架

 解決前端特定領(lǐng)域問題的代碼組織框架，約束性體現(xiàn)為需要基于約定的結(jié)構(gòu)來組織代碼，支撐性體現(xiàn)為基于框架內(nèi)置的機(jī)制或能力高效的實(shí)現(xiàn)功能。

按這個(gè)定義 JS 框架覆蓋了方方面面，例如解決 Web 整體實(shí)現(xiàn)的前端應(yīng)用框架、游戲引擎框架、后端服務(wù)框架等等，但需要指出的是大家通常認(rèn)為的 JS 框架指的是前端應(yīng)用框架，這也是這部分文章介紹的重點(diǎn)。

再順道說一下框架和庫(kù)的區(qū)別，JS 庫(kù)通常是解決系統(tǒng)構(gòu)建中某個(gè)子問題的代碼實(shí)現(xiàn)，它和框架的關(guān)系往往是被調(diào)用者（庫(kù)）和調(diào)用者（框架）的關(guān)系。

JS 框架要解決什么問題

一直以來 Web 前端技術(shù)發(fā)展非常迅速，新技術(shù)更是層出不窮，但這些技術(shù)發(fā)展的背后始終圍繞著一條主線——如何更高效的構(gòu)建 Web 人機(jī)交互界面。復(fù)雜 Web 應(yīng)用的構(gòu)建首先要考慮的是如何更合理的組織代碼，這關(guān)系到協(xié)作效率、可維護(hù)性、可擴(kuò)展性等等，本質(zhì)是對(duì)生產(chǎn)效率的持續(xù)追求。

再進(jìn)一步拆解來看，我們的問題域主要包括視圖構(gòu)建、視圖狀態(tài)管理、用戶交互、服務(wù)端交互等，在復(fù)雜場(chǎng)景下，隨著表達(dá)內(nèi)容和人機(jī)交互多樣性的增加，如何兼具效率、體驗(yàn)等具有較大的挑戰(zhàn)，而這也恰恰是 JS 框架所要解決的問題。

三、JavaScript 框架的發(fā)展

從 Tim Berners-Lee 在 1989 年的提議開始到 2019 年 3 月 12 日，WWW 迎來了它的 30 歲生日， 這 30 年無疑是人類科技進(jìn)步最快的 30 年，Web 也從最初的提議變成了人類社會(huì)的基礎(chǔ)設(shè)施。

從技術(shù)角度看，Web 在滿足人們?cè)絹碓蕉嗑€上化需求的同時(shí)，Web 前端也在變得越來越復(fù)雜：更強(qiáng)大的功能、更豐富多樣的內(nèi)容、更復(fù)雜的運(yùn)行環(huán)境等等，從最初的小制作到現(xiàn)在的大規(guī)模復(fù)雜應(yīng)用，不斷推動(dòng)開發(fā)者們尋求更高效的前端構(gòu)建方式，這也正是前端技術(shù)快速發(fā)展背后的動(dòng)力。

互聯(lián)網(wǎng)用戶增長(zhǎng)

從 Web 前端的形式看，大致可以將 30 年劃分為三個(gè)時(shí)期：只讀 Web 時(shí)期、可交互 Web 時(shí)期、Web 應(yīng)用時(shí)期。

只讀 Web 時(shí)期（1990~2000），Web 的核心功能是圖文內(nèi)容的線上化，只有少數(shù)用戶使用并且只能瀏覽內(nèi)容。從技術(shù)角度看，這個(gè)時(shí)代是 Web 標(biāo)準(zhǔn)的起源階段，同時(shí)由于單一的內(nèi)容表現(xiàn)需求，尚不存在誕生 JS 框架的土壤。

可交互 Web 時(shí)期（2000~2010），越來越多的人通過 Web 滿足需求，Web 內(nèi)容形態(tài)也從單一的只讀圖文展示演變成功能豐富的可交互形式，這種演變也促使 Web 開發(fā)領(lǐng)域演化出新的社會(huì)分工角色 —— Web 前端工程師。與此同時(shí)，有了 JS 框架的土壤之后，形形色色的前端庫(kù)和框架也逐漸誕生，但此時(shí)它們更多專注于解決某個(gè)方向的問題：例如兼容性或者組件化等等；

Web 應(yīng)用時(shí)期（2010 至今），對(duì)于很多行業(yè)而言，Web 服務(wù)已經(jīng)屬于基礎(chǔ)設(shè)施，大多數(shù)人已經(jīng)依賴 Web 能力來滿足需求。為了追求更好的體驗(yàn)以及更高的效率，Web 服務(wù)的構(gòu)建也像客戶端應(yīng)用靠齊，JS 框架的發(fā)展則逐步覆蓋到高效構(gòu)建 Web 前端相關(guān)的整個(gè)領(lǐng)域。

只讀 Web 時(shí)期

1989 年，為了讓學(xué)校和科研機(jī)構(gòu)間能夠更高效的共享信息，Tim Berners-Lee 提出了「WWW」提議并且在次年發(fā)明了第一個(gè) web 瀏覽器 - WorldWideWeb。而在隨后的 1991 年，HTML 的第一個(gè)版本 - 「HTML Tags」誕生，目標(biāo)是文本、圖片等信息的在線展示以及互聯(lián)互通。

第一個(gè)商業(yè)化瀏覽器的誕生則是在 1993 年，來自 Netscape 的 Netscape Navigator。W3C 的誕生則要到 1994 年，由 Tim Berners-Lee 創(chuàng)辦。

Netscape Navigator 1.0

直至 1995 年，Web 上所有內(nèi)容仍然是純靜態(tài)，但隨著 Web 需求的快速增長(zhǎng)，逐步有些場(chǎng)景需要用戶交互的能力，因此在 1995 年 9 月，Netscape 發(fā)布了 Javascript 的第一個(gè)版本 - LiveScript，并在 3 個(gè)月后改名為 JavaScript。

20 世紀(jì) 90 年代中期 apple 官網(wǎng)

這一時(shí)期除了 WWW 的起源之外，另一件值得一提的事是史上第一次「瀏覽器大戰(zhàn)」，在這場(chǎng)大戰(zhàn)中，Netscape 在前期以先發(fā)優(yōu)勢(shì)拿下 80% 的市場(chǎng)份額，微軟 IE 則后來居上，以和 Windows 捆綁的方式逐步贏回優(yōu)勢(shì)，到 2000 年微軟 IE 市場(chǎng)份額占比超過 80%。

有意思的是在第二次「瀏覽器大戰(zhàn)」中，IE 又?jǐn)∠玛噥?，后起之?Chrome 借著更高的性能、更好的標(biāo)準(zhǔn)兼容性以及更快的迭代速度攻城掠地，至 2019 年占領(lǐng) 70% 以上的市場(chǎng)份額，IE 市場(chǎng)份額則降至 10% 左右。

對(duì)開發(fā)者而言，「瀏覽器大戰(zhàn)」中由于各方對(duì)標(biāo)準(zhǔn)的支持程度有差異，甚至為了實(shí)現(xiàn)差異化會(huì)特意引入新特性，因此開發(fā)者需要投入大量的工作來解決兼容性問題，這也為后續(xù)的 Javascript 庫(kù)/框架的產(chǎn)生埋下伏筆。

瀏覽器市場(chǎng)份額(1996-2009)

瀏覽器市場(chǎng)份額(2008-2019)

可交互 Web 時(shí)期

進(jìn)入 2000 年，互聯(lián)網(wǎng)加速發(fā)展，隨著電商、社交等新平臺(tái)的推出，越來越多用戶加入互聯(lián)網(wǎng)，此時(shí)的互聯(lián)網(wǎng)用戶群已經(jīng)逐步由最初的小眾用戶發(fā)展為大眾用戶，各大平臺(tái)也越來越重視 Web 用戶體驗(yàn)，開始在 Web 用戶交互方面增加資源投入。

另一方面，瀏覽器通過持續(xù)的升級(jí)也具備更多的能力來支撐更好的用戶交互，例如異步請(qǐng)求能力的引入等。以上需求和供給兩側(cè)為 JavaScript 庫(kù)/框架的發(fā)展提供了土壤。

這個(gè)階段，Web 主流的渲染方式是后端渲染，JavaScript 的重點(diǎn)工作是對(duì)頁(yè)面實(shí)現(xiàn)局部交互能力，例如表單驗(yàn)證、異步提交、圖片輪播、Tab 切換等等，這一時(shí)期的 JavaScript 庫(kù)/框架圍繞完善用戶交互相關(guān)基礎(chǔ)設(shè)施發(fā)展，主要包括組件化、兼容性以及工具庫(kù)。

組件化

與其他編程語(yǔ)言中的人機(jī)交互界面構(gòu)建能力相比，在 Web 中缺乏豐富、標(biāo)準(zhǔn)化的 UI 組件庫(kù)。因此在這個(gè)階段涌現(xiàn)出一批以組件化為主的框架，其中比較有代表性的是 DoJo(2005)、ExtJS(2007)。這些框架的特點(diǎn)是提供了 All in One 的組件庫(kù)，組件類型豐富，當(dāng)然交互形式也非常厚重，典型的桌面客戶端風(fēng)格。

DoJo Toolkit Widgets

兼容性

「瀏覽器大戰(zhàn)」的大背景下，瀏覽器廠商各自為戰(zhàn)，于是不論是 BOM、DOM 還是 JavaScript 層面都需要做大量的兼容性工作，于是 jQuery(2006) 便在這一背景下誕生。

jQuery 一方面解決了大量兼容性問題，另一方面提供了非常便捷的基于 CSS 選擇符的 DOM 獲取方式以及 DOM 操作能力，此外還重新封裝了異步請(qǐng)求的 API，這些能力在以命令式（imperative）編程范式為主的時(shí)期是非常高頻的操作，因此 jQuery 的出現(xiàn)大大提升了前端編程體驗(yàn)和效率。

<script>
$( "div span:first-child" )
  .css( "text-decoration", "underline" )
  .hover(function() {
    $( this ).addClass( "sogreen" );
  }, function() {
    $( this ).removeClass( "sogreen" );
  });
</script>

當(dāng)然，隨著 jQuery 很多能力從事實(shí)標(biāo)準(zhǔn)演進(jìn)為正式標(biāo)準(zhǔn)，瀏覽器開始提供原生支持，再者前端編程模式從命令式向聲明式（declarative）演進(jìn)，針對(duì) DOM 的獲取與操作大大減少，jQuery 的使用率也隨之快速下降。此外，隨著 Chrome 在「瀏覽器大戰(zhàn)」中勝出，兼容性問題已經(jīng)有了非常大的改善，當(dāng)然移動(dòng)端除外。

工具庫(kù)

這一時(shí)期原生 JavaScript 僅支持一些較「原始」的編碼能力，對(duì)比其他成熟的編程語(yǔ)言而言在編程效率和體驗(yàn)上都存在巨大差異，各類工具庫(kù)基于「原始」能力進(jìn)行再封裝，能較大程度縮小差異。工具庫(kù)類的代表有 PrototypeJS(2005)、YUI(2006)、Mootools(2007)，它們主要針對(duì)面向?qū)ο?、事件、異步?qǐng)求、數(shù)組操作等方面進(jìn)行了封裝。

/*PrototypeJS 代碼示例*/
// 面向?qū)ο?/span>
var FirstClass = Class.create( {
    // The initialize method serves as a constructor
    initialize: function () {
        this.data = "Hello World";
    }
});
// 異步請(qǐng)求
Ajax.Request = Class.create( Ajax.Base, {  
    // Override the initialize method
    initialize: function(url, options) {  
        this.transport = Ajax.getTransport();  
        this.setOptions(options);  
        this.request(url);  
    },  
    // ...more methods add ...  
});
// DOM 與事件
$$('#items li').each( function(item) {
  item.observe('click', function(event) {
    doSomethingWith(event.target);
  });
});
// 數(shù)組遍歷
myArray.each(function(item) {
  // Your code working on item here...
});

當(dāng)然，按上述三個(gè)方面并不是能夠特別準(zhǔn)確的去給眾多 JavaScript 庫(kù)/框架進(jìn)行歸類，很多采用分層以及可拆解的設(shè)計(jì)，能夠同時(shí)兼顧各個(gè)方面的需求，就如以下 YUI 的整體架構(gòu)。

Web 應(yīng)用時(shí)期

最近 10 年，隨著前端投入的持續(xù)增加，前端團(tuán)隊(duì)的話語(yǔ)權(quán)也越來越重，同時(shí)大家也在持續(xù)探索更高效的前端研發(fā)模式，例如這期間逐步發(fā)展的前后端分離、前端工程化等，尤其是前后端分離的協(xié)作模式給前端開發(fā)帶來了更高的自由度和空間，前端的工作職責(zé)從最初的局部動(dòng)態(tài)化、局部可交互逐步擴(kuò)張到整站的前端構(gòu)建。

這種變化直接帶來了至少兩方面的挑戰(zhàn)，一是如何解決多人協(xié)作問題，針對(duì)規(guī)模越來越大的前端工程，多人協(xié)作是必然，而協(xié)作的關(guān)鍵是明確的分工和合作；二是代碼的可維護(hù)性問題，在前端框架出現(xiàn)之前，局部動(dòng)態(tài) UI 通常采用前端模板加命令式編程范式來實(shí)現(xiàn)，這種方式對(duì)于輕量的 UI 構(gòu)建是可接受的，但在應(yīng)對(duì)大規(guī)模前端功能構(gòu)建時(shí)，很容易寫出可維護(hù)性極差的代碼。

這些是構(gòu)建 GUI 應(yīng)用時(shí)的典型問題，在 Web 前端出現(xiàn)之前的其他平臺(tái)的 GUI 構(gòu)建中也有類似的問題，解決的方式是引入合適的架構(gòu)模式，將看似亂做一團(tuán)的代碼分門別類，各自關(guān)注各自職責(zé)范圍內(nèi)的工作，這些架構(gòu)模式包括 MVC、MVP、MVVM 等等，背后的核心理念是「關(guān)注點(diǎn)分離」。

在 Web 前端面臨類似的挑戰(zhàn)時(shí)，自然而然的是借鑒傳統(tǒng) GUI 構(gòu)建的經(jīng)驗(yàn)，通過框架的形式引入新的架構(gòu)模式來解決，在這一背景下前端也逐步出現(xiàn)了真正意義上的「框架」。

2010 年發(fā)布的 Backbone.js 引入了視圖和數(shù)據(jù)模型的概念，但它并不是標(biāo)準(zhǔn)的 MVC 實(shí)現(xiàn)，沒有明確的控制器概念，而是由視圖承擔(dān)部分控制器職責(zé)，但這些并不重要，重要的是前端 GUI 構(gòu)建有了新的思路和選擇。

另外一點(diǎn)值得一提的是，Backbone.js 仍然采用了命令式編程范式，這在前端 GUI 構(gòu)建中與后續(xù)逐漸流行的聲明式編程范式而言，編程效率上會(huì)有明顯的差距。

/*Backbone.js 代碼示例（部分）詳細(xì)前往 https://backbonejs.org/docs/todos.html*/
var AppView = Backbone.View.extend({
    el: $("#todoapp"),
    statsTemplate: _.template($('#stats-template').html()),
    events: {
      "keypress #new-todo":  "createOnEnter",
    },
    initialize: function() {
      this.input = this.$("#new-todo");
      this.listenTo(Todos, 'add', this.addOne);
      this.footer = this.$('footer');
      this.main = $('#main');
      Todos.fetch();
    },
    render: function() {
      var done = Todos.done().length;
      var remaining = Todos.remaining().length;
      if (Todos.length) {
        this.main.show();
        this.footer.show();
        this.footer.html(this.statsTemplate({done: done, remaining: remaining}));
      } else {
        this.main.hide();
        this.footer.hide();
      }
      this.allCheckbox.checked = !remaining;
    },
    addOne: function(todo) {
      var view = new TodoView({model: todo});
      this.$("#todo-list").append(view.render().el);
    },
    clearCompleted: function() {
      _.invoke(Todos.done(), 'destroy');
      return false;
    }
  });
  var App = new AppView;
});

同年 AngularJS 發(fā)布第一個(gè)版本，和 Backbone 的最大不同，一方面它充分借鑒了微軟 WPF 的 MVVM 架構(gòu)模式，引入 VM 概念，支持視圖和數(shù)據(jù)的雙向綁定；另一方面它采用了聲明式的視圖構(gòu)建模式，大大減少了原生 DOM 操作。

此外，AngularJS 提供的功能非常全面（路由管理、組件化、視圖模板、狀態(tài)管理、后端交互、事件管理、動(dòng)畫等），基本達(dá)到開箱即用的狀態(tài)，使用它能夠非常高效的構(gòu)建 SPA 類應(yīng)用。

當(dāng)然，它的缺點(diǎn)也非常明顯，引入了過多的概念導(dǎo)致上手成本非常高，此外它的「大而全」是優(yōu)點(diǎn)的同時(shí)也是缺點(diǎn)，對(duì)于非 SPA 類 Web 場(chǎng)景而言過于臃腫。總體而言，AngularJS 對(duì)于解決特定場(chǎng)景中的前端架構(gòu)問題是非常有效的，能夠非常顯著的提升前端協(xié)作效率。

AngularJS 示例

在 AngularJS 發(fā)布后的第四年和第五年 React 以及 Vue 陸續(xù)發(fā)布，React 發(fā)布時(shí)的目標(biāo)是優(yōu)化視圖構(gòu)建，但隨著整個(gè)生態(tài)的完善，React 已經(jīng)有充分的能力支撐大規(guī)模的前端應(yīng)用開發(fā)。Vue 則借鑒了 AngularJS 的架構(gòu)模式，并且同樣采用了聲明式的視圖構(gòu)建方式。

相比 AngularJS，React 和 Vue 的最大優(yōu)勢(shì)是更加的輕量和靈活，能夠適應(yīng)更多的場(chǎng)景，此外上手成本也要低得多，尤其是 Vue，這也讓后兩者在最近幾年能夠碾壓 AngularJS。

縱觀最近 10 年前端框架的變遷，有兩點(diǎn)得以驗(yàn)證，一是聲明式編程范式相比命令式在前端 GUI 構(gòu)建中的成功，背后的關(guān)鍵邏輯是研發(fā)效率的顯著優(yōu)勢(shì)；二是漸進(jìn)式框架相比 All in One 「全家桶」式框架的成功，漸進(jìn)式框架有更好的靈活性，面對(duì)前端場(chǎng)景的變化有更強(qiáng)的適應(yīng)性。

四、鑒往知來

以上走馬觀花的概覽了最近 30 年前端框架的發(fā)展，整體演進(jìn)脈絡(luò)是清晰的，Web 前端從無到有，從有到逐步走向?qū)I(yè)化，技術(shù)上的關(guān)注點(diǎn)和挑戰(zhàn)也在不斷變化，從解決最初的 DOM 操作效率、兼容性、組件化等問題，再到提升大規(guī)模前端的協(xié)作效率等，那些能夠準(zhǔn)確把握并且有效解決問題的框架/庫(kù)都獲得了成功，至少是階段性的成功。順著這條脈絡(luò)往前看，前端框架的后續(xù)發(fā)展仍然取決于前端領(lǐng)域在未來將面臨何種挑戰(zhàn)。

Web vs Native

在智能手機(jī)普及的初期，各平臺(tái)的移動(dòng)端也曾經(jīng)以 Web 為主，當(dāng)時(shí)各種 Web 服務(wù)的 m 站是必備之一。隨著智能手機(jī)的普及，移動(dòng) APP 具備明顯的路徑、性能、能力等方面的優(yōu)勢(shì)，迅速成為移動(dòng)化的首選。在這個(gè)過程中，Web 前端很大程度上淡出移動(dòng)應(yīng)用的核心研發(fā)工作，后來隨著 hybrid 開發(fā)模式的成熟，Web 前端又逐步參與到一些移動(dòng)應(yīng)用的開發(fā)中。

再看未來，逐步由流量運(yùn)營(yíng)到以用戶運(yùn)營(yíng)為核心的時(shí)期，以 Native 為主導(dǎo)的模式預(yù)計(jì)仍然會(huì)是主流，而且用戶體驗(yàn)變得更加重要，尤其是用戶長(zhǎng)停留的應(yīng)用。在這一背景下，Web 和 Native 如何更好的協(xié)作，如何取長(zhǎng)補(bǔ)短，在效率和體驗(yàn)上能夠進(jìn)一步突破天花板將是長(zhǎng)期的挑戰(zhàn)。

智能終端

前面更多談?wù)摰氖?PC 端和移動(dòng)端，隨著 5G 的完善和普及，IoT 會(huì)迎來加速發(fā)展，屆時(shí)在移動(dòng)端和 PC 端兩端之外將會(huì)出現(xiàn)更多形式各異的終端，這類終端的 GUI 需求如何解決，是否可以采用 Web 技術(shù)來提效，現(xiàn)有 Web 框架在 IoT 設(shè)備上是否是最佳選擇？隨著 IoT 的爆發(fā)，這些問題會(huì)是前端框架不得不考慮的問題。

低代碼化

另外一個(gè)看得見的趨勢(shì)是低代碼化（low/no code）的普及，不久的將來大量的模式化的 Web 開發(fā)工作極大可能將通過低代碼化的方式來解決，例如運(yùn)營(yíng)、管理類的平臺(tái)就是典型的模式化 Web 平臺(tái)，這類平臺(tái)在當(dāng)前的前端研發(fā)工作中占有很大的比例，也是當(dāng)前各類前端框架的重要應(yīng)用場(chǎng)景，一旦這類需求由低代碼化的方式來實(shí)現(xiàn)，那么具體的實(shí)現(xiàn)使用何種框架將變得不那么重要。

在這個(gè)背景下，很可能會(huì)誕生一些專有框架來更高效的解決低代碼化的領(lǐng)域問題。而通用類框架的場(chǎng)景會(huì)更多的集中在非模式化的場(chǎng)景中，在這類場(chǎng)景中對(duì)框架的靈活性、定制化等會(huì)有更高的要求。