建站
咨詢
售后
建站咨詢
新聞中心
一、前言
10年積累的做網(wǎng)站、成都網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有永吉免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
關(guān)于 JS 框架部分能聊的內(nèi)容比較多，我相信大家對某個框架的使用、原理等知識是比較容易找到資料來學(xué)習(xí)的，鑒于此這部分內(nèi)容將會從另一個視角出發(fā)：通過回顧 JS 框架的發(fā)展歷程，和大家一起探討框架的本質(zhì)以及 JS 框架不斷變化背后的驅(qū)動力。正所謂「鑒往知來」，希望大家能對 JS 框架有更全面的認(rèn)知，能夠把握變化背后不變的邏輯，更好的應(yīng)對未來新的變化。
二、什么是框架
在講清楚一件事情之前，我們需要先準(zhǔn)確定義它，這一部分我們先定義清楚什么是框架以及什么是 JS 框架。
先看一個通用意義上「框架」的的定義：
框架（framework）是一個框子——指其約束性，也是一個架子——指其支撐性。是一個基本概念上的結(jié)構(gòu)，用于去解決或者處理復(fù)雜的問題。
個人非常喜歡這個定義，簡潔而準(zhǔn)確，框架的核心就是「約束性」和「支撐性」。
如何理解「約束性」
框架是解決復(fù)雜領(lǐng)域問題的系統(tǒng)性方法，對于復(fù)雜問題而言，往往缺失「銀彈」，大家看問題的角度會有差異，每個框架背后都有自己的理念，當(dāng)你選擇某個框架就需要遵循它的邏輯和規(guī)則，在規(guī)則之內(nèi)解決問題，這是「約束性」。
如何理解「支撐性」
復(fù)雜問題通常可以拆解成一系列小問題，問題的整體解法則是如何解決它們中的所有或者部分，框架的「支撐性」體現(xiàn)在它提供了問題的定義和一系列解決問題的方法，基于它能夠?qū)⑨槍Ω鱾€子問題的解法更加有序的組織起來，最終形成整體的解法，「支撐性」即有序組織。
如何定義 JS 框架
解決前端特定領(lǐng)域問題的代碼組織框架，約束性體現(xiàn)為需要基于約定的結(jié)構(gòu)來組織代碼，支撐性體現(xiàn)為基于框架內(nèi)置的機(jī)制或能力高效的實現(xiàn)功能。
按這個定義 JS 框架覆蓋了方方面面，例如解決 Web 整體實現(xiàn)的前端應(yīng)用框架、游戲引擎框架、后端服務(wù)框架等等，但需要指出的是大家通常認(rèn)為的 JS 框架指的是前端應(yīng)用框架，這也是這部分文章介紹的重點。
再順道說一下框架和庫的區(qū)別，JS 庫通常是解決系統(tǒng)構(gòu)建中某個子問題的代碼實現(xiàn)，它和框架的關(guān)系往往是被調(diào)用者（庫）和調(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ì)是對生產(chǎn)效率的持續(xù)追求。
再進(jìn)一步拆解來看，我們的問題域主要包括視圖構(gòu)建、視圖狀態(tài)管理、用戶交互、服務(wù)端交互等，在復(fù)雜場景下，隨著表達(dá)內(nèi)容和人機(jī)交互多樣性的增加，如何兼具效率、體驗等具有較大的挑戰(zhàn)，而這也恰恰是 JS 框架所要解決的問題。
三、JavaScript 框架的發(fā)展
從 Tim Berners-Lee 在 1989 年的提議開始到 2019 年 3 月 12 日，WWW 迎來了它的 30 歲生日， 這 30 年無疑是人類科技進(jìn)步最快的 30 年，Web 也從最初的提議變成了人類社會的基礎(chǔ)設(shè)施。
從技術(shù)角度看，Web 在滿足人們越來越多線上化需求的同時，Web 前端也在變得越來越復(fù)雜：更強(qiáng)大的功能、更豐富多樣的內(nèi)容、更復(fù)雜的運(yùn)行環(huán)境等等，從最初的小制作到現(xiàn)在的大規(guī)模復(fù)雜應(yīng)用，不斷推動開發(fā)者們尋求更高效的前端構(gòu)建方式，這也正是前端技術(shù)快速發(fā)展背后的動力。
互聯(lián)網(wǎng)用戶增長
從 Web 前端的形式看，大致可以將 30 年劃分為三個時期：只讀 Web 時期、可交互 Web 時期、Web 應(yīng)用時期。
只讀 Web 時期（1990~2000），Web 的核心功能是圖文內(nèi)容的線上化，只有少數(shù)用戶使用并且只能瀏覽內(nèi)容。從技術(shù)角度看，這個時代是 Web 標(biāo)準(zhǔn)的起源階段，同時由于單一的內(nèi)容表現(xiàn)需求，尚不存在誕生 JS 框架的土壤。
可交互 Web 時期（2000~2010），越來越多的人通過 Web 滿足需求，Web 內(nèi)容形態(tài)也從單一的只讀圖文展示演變成功能豐富的可交互形式，這種演變也促使 Web 開發(fā)領(lǐng)域演化出新的社會分工角色 —— Web 前端工程師。與此同時，有了 JS 框架的土壤之后，形形色色的前端庫和框架也逐漸誕生，但此時它們更多專注于解決某個方向的問題：例如兼容性或者組件化等等；
Web 應(yīng)用時期（2010 至今），對于很多行業(yè)而言，Web 服務(wù)已經(jīng)屬于基礎(chǔ)設(shè)施，大多數(shù)人已經(jīng)依賴 Web 能力來滿足需求。為了追求更好的體驗以及更高的效率，Web 服務(wù)的構(gòu)建也像客戶端應(yīng)用靠齊，JS 框架的發(fā)展則逐步覆蓋到高效構(gòu)建 Web 前端相關(guān)的整個領(lǐng)域。
只讀 Web 時期
1989 年，為了讓學(xué)校和科研機(jī)構(gòu)間能夠更高效的共享信息，Tim Berners-Lee 提出了「WWW」提議并且在次年發(fā)明了第一個 web 瀏覽器 - WorldWideWeb。而在隨后的 1991 年，HTML 的第一個版本 - 「HTML Tags」誕生，目標(biāo)是文本、圖片等信息的在線展示以及互聯(lián)互通。
第一個商業(yè)化瀏覽器的誕生則是在 1993 年，來自 Netscape 的 Netscape Navigator。W3C 的誕生則要到 1994 年，由 Tim Berners-Lee 創(chuàng)辦。
Netscape Navigator 1.0
直至 1995 年，Web 上所有內(nèi)容仍然是純靜態(tài)，但隨著 Web 需求的快速增長，逐步有些場景需要用戶交互的能力，因此在 1995 年 9 月，Netscape 發(fā)布了 Javascript 的第一個版本 - LiveScript，并在 3 個月后改名為 JavaScript。
20 世紀(jì) 90 年代中期 apple 官網(wǎng)
這一時期除了 WWW 的起源之外，另一件值得一提的事是史上第一次「瀏覽器大戰(zhàn)」，在這場大戰(zhàn)中，Netscape 在前期以先發(fā)優(yōu)勢拿下 80% 的市場份額，微軟 IE 則后來居上，以和 Windows 捆綁的方式逐步贏回優(yōu)勢，到 2000 年微軟 IE 市場份額占比超過 80%。
有意思的是在第二次「瀏覽器大戰(zhàn)」中，IE 又?jǐn)∠玛噥?，后起之?Chrome 借著更高的性能、更好的標(biāo)準(zhǔn)兼容性以及更快的迭代速度攻城掠地，至 2019 年占領(lǐng) 70% 以上的市場份額，IE 市場份額則降至 10% 左右。
對開發(fā)者而言，「瀏覽器大戰(zhàn)」中由于各方對標(biāo)準(zhǔn)的支持程度有差異，甚至為了實現(xiàn)差異化會特意引入新特性，因此開發(fā)者需要投入大量的工作來解決兼容性問題，這也為后續(xù)的 Javascript 庫/框架的產(chǎn)生埋下伏筆。
瀏覽器市場份額(1996-2009)
瀏覽器市場份額(2008-2019)
可交互 Web 時期
進(jìn)入 2000 年，互聯(lián)網(wǎng)加速發(fā)展，隨著電商、社交等新平臺的推出，越來越多用戶加入互聯(lián)網(wǎng)，此時的互聯(lián)網(wǎng)用戶群已經(jīng)逐步由最初的小眾用戶發(fā)展為大眾用戶，各大平臺也越來越重視 Web 用戶體驗，開始在 Web 用戶交互方面增加資源投入。
另一方面，瀏覽器通過持續(xù)的升級也具備更多的能力來支撐更好的用戶交互，例如異步請求能力的引入等。以上需求和供給兩側(cè)為 JavaScript 庫/框架的發(fā)展提供了土壤。
這個階段，Web 主流的渲染方式是后端渲染，JavaScript 的重點工作是對頁面實現(xiàn)局部交互能力，例如表單驗證、異步提交、圖片輪播、Tab 切換等等，這一時期的 JavaScript 庫/框架圍繞完善用戶交互相關(guān)基礎(chǔ)設(shè)施發(fā)展，主要包括組件化、兼容性以及工具庫。
組件化
與其他編程語言中的人機(jī)交互界面構(gòu)建能力相比，在 Web 中缺乏豐富、標(biāo)準(zhǔn)化的 UI 組件庫。因此在這個階段涌現(xiàn)出一批以組件化為主的框架，其中比較有代表性的是 DoJo(2005)、ExtJS(2007)。這些框架的特點是提供了 All in One 的組件庫，組件類型豐富，當(dāng)然交互形式也非常厚重，典型的桌面客戶端風(fēng)格。
DoJo Toolkit Widgets
兼容性
「瀏覽器大戰(zhàn)」的大背景下，瀏覽器廠商各自為戰(zhàn)，于是不論是 BOM、DOM 還是 JavaScript 層面都需要做大量的兼容性工作，于是 jQuery(2006) 便在這一背景下誕生。
jQuery 一方面解決了大量兼容性問題，另一方面提供了非常便捷的基于 CSS 選擇符的 DOM 獲取方式以及 DOM 操作能力，此外還重新封裝了異步請求的 API，這些能力在以命令式（imperative）編程范式為主的時期是非常高頻的操作，因此 jQuery 的出現(xiàn)大大提升了前端編程體驗和效率。
當(dāng)然，隨著 jQuery 很多能力從事實標(biāo)準(zhǔn)演進(jìn)為正式標(biāo)準(zhǔn)，瀏覽器開始提供原生支持，再者前端編程模式從命令式向聲明式（declarative）演進(jìn)，針對 DOM 的獲取與操作大大減少，jQuery 的使用率也隨之快速下降。此外，隨著 Chrome 在「瀏覽器大戰(zhàn)」中勝出，兼容性問題已經(jīng)有了非常大的改善，當(dāng)然移動端除外。
工具庫
這一時期原生 JavaScript 僅支持一些較「原始」的編碼能力，對比其他成熟的編程語言而言在編程效率和體驗上都存在巨大差異，各類工具庫基于「原始」能力進(jìn)行再封裝，能較大程度縮小差異。工具庫類的代表有 PrototypeJS(2005)、YUI(2006)、Mootools(2007)，它們主要針對面向?qū)ο?、事件、異步請求、?shù)組操作等方面進(jìn)行了封裝。
/*PrototypeJS 代碼示例*/
// 面向?qū)ο?br>var FirstClass = Class.create( {
// The initialize method serves as a constructor
initialize: function () {
this.data = "Hello World";
}
});
// 異步請求
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)然，按上述三個方面并不是能夠特別準(zhǔn)確的去給眾多 JavaScript 庫/框架進(jìn)行歸類，很多采用分層以及可拆解的設(shè)計，能夠同時兼顧各個方面的需求，就如以下 YUI 的整體架構(gòu)。
Web 應(yīng)用時期
最近 10 年，隨著前端投入的持續(xù)增加，前端團(tuán)隊的話語權(quán)也越來越重，同時大家也在持續(xù)探索更高效的前端研發(fā)模式，例如這期間逐步發(fā)展的前后端分離、前端工程化等，尤其是前后端分離的協(xié)作模式給前端開發(fā)帶來了更高的自由度和空間，前端的工作職責(zé)從最初的局部動態(tài)化、局部可交互逐步擴(kuò)張到整站的前端構(gòu)建。
這種變化直接帶來了至少兩方面的挑戰(zhàn)，一是如何解決多人協(xié)作問題，針對規(guī)模越來越大的前端工程，多人協(xié)作是必然，而協(xié)作的關(guān)鍵是明確的分工和合作；二是代碼的可維護(hù)性問題，在前端框架出現(xiàn)之前，局部動態(tài) UI 通常采用前端模板加命令式編程范式來實現(xiàn)，這種方式對于輕量的 UI 構(gòu)建是可接受的，但在應(yīng)對大規(guī)模前端功能構(gòu)建時，很容易寫出可維護(hù)性極差的代碼。
這些是構(gòu)建 GUI 應(yīng)用時的典型問題，在 Web 前端出現(xiàn)之前的其他平臺的 GUI 構(gòu)建中也有類似的問題，解決的方式是引入合適的架構(gòu)模式，將看似亂做一團(tuán)的代碼分門別類，各自關(guān)注各自職責(zé)范圍內(nèi)的工作，這些架構(gòu)模式包括 MVC、MVP、MVVM 等等，背后的核心理念是「關(guān)注點分離」。
在 Web 前端面臨類似的挑戰(zhàn)時，自然而然的是借鑒傳統(tǒng) GUI 構(gòu)建的經(jīng)驗，通過框架的形式引入新的架構(gòu)模式來解決，在這一背景下前端也逐步出現(xiàn)了真正意義上的「框架」。
2010 年發(fā)布的 Backbone.js 引入了視圖和數(shù)據(jù)模型的概念，但它并不是標(biāo)準(zhǔn)的 MVC 實現(xiàn)，沒有明確的控制器概念，而是由視圖承擔(dān)部分控制器職責(zé)，但這些并不重要，重要的是前端 GUI 構(gòu)建有了新的思路和選擇。
另外一點值得一提的是，Backbone.js 仍然采用了命令式編程范式，這在前端 GUI 構(gòu)建中與后續(xù)逐漸流行的聲明式編程范式而言，編程效率上會有明顯的差距。
/*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ā)布第一個版本，和 Backbone 的最大不同，一方面它充分借鑒了微軟 WPF 的 MVVM 架構(gòu)模式，引入 VM 概念，支持視圖和數(shù)據(jù)的雙向綁定；另一方面它采用了聲明式的視圖構(gòu)建模式，大大減少了原生 DOM 操作。
此外，AngularJS 提供的功能非常全面（路由管理、組件化、視圖模板、狀態(tài)管理、后端交互、事件管理、動畫等），基本達(dá)到開箱即用的狀態(tài)，使用它能夠非常高效的構(gòu)建 SPA 類應(yīng)用。
當(dāng)然，它的缺點也非常明顯，引入了過多的概念導(dǎo)致上手成本非常高，此外它的「大而全」是優(yōu)點的同時也是缺點，對于非 SPA 類 Web 場景而言過于臃腫?？傮w而言，AngularJS 對于解決特定場景中的前端架構(gòu)問題是非常有效的，能夠非常顯著的提升前端協(xié)作效率。
AngularJS 示例
在 AngularJS 發(fā)布后的第四年和第五年 React 以及 Vue 陸續(xù)發(fā)布，React 發(fā)布時的目標(biāo)是優(yōu)化視圖構(gòu)建，但隨著整個生態(tài)的完善，React 已經(jīng)有充分的能力支撐大規(guī)模的前端應(yīng)用開發(fā)。Vue 則借鑒了 AngularJS 的架構(gòu)模式，并且同樣采用了聲明式的視圖構(gòu)建方式。
相比 AngularJS，React 和 Vue 的最大優(yōu)勢是更加的輕量和靈活，能夠適應(yīng)更多的場景，此外上手成本也要低得多，尤其是 Vue，這也讓后兩者在最近幾年能夠碾壓 AngularJS。
縱觀最近 10 年前端框架的變遷，有兩點得以驗證，一是聲明式編程范式相比命令式在前端 GUI 構(gòu)建中的成功，背后的關(guān)鍵邏輯是研發(fā)效率的顯著優(yōu)勢；二是漸進(jìn)式框架相比 All in One 「全家桶」式框架的成功，漸進(jìn)式框架有更好的靈活性，面對前端場景的變化有更強(qiáng)的適應(yīng)性。
四、鑒往知來
以上走馬觀花的概覽了最近 30 年前端框架的發(fā)展，整體演進(jìn)脈絡(luò)是清晰的，Web 前端從無到有，從有到逐步走向?qū)I(yè)化，技術(shù)上的關(guān)注點和挑戰(zhàn)也在不斷變化，從解決最初的 DOM 操作效率、兼容性、組件化等問題，再到提升大規(guī)模前端的協(xié)作效率等，那些能夠準(zhǔn)確把握并且有效解決問題的框架/庫都獲得了成功，至少是階段性的成功。順著這條脈絡(luò)往前看，前端框架的后續(xù)發(fā)展仍然取決于前端領(lǐng)域在未來將面臨何種挑戰(zhàn)。
Web vs Native
在智能手機(jī)普及的初期，各平臺的移動端也曾經(jīng)以 Web 為主，當(dāng)時各種 Web 服務(wù)的 m 站是必備之一。隨著智能手機(jī)的普及，移動 APP 具備明顯的路徑、性能、能力等方面的優(yōu)勢，迅速成為移動化的首選。在這個過程中，Web 前端很大程度上淡出移動應(yīng)用的核心研發(fā)工作，后來隨著 hybrid 開發(fā)模式的成熟，Web 前端又逐步參與到一些移動應(yīng)用的開發(fā)中。
再看未來，逐步由流量運(yùn)營到以用戶運(yùn)營為核心的時期，以 Native 為主導(dǎo)的模式預(yù)計仍然會是主流，而且用戶體驗變得更加重要，尤其是用戶長停留的應(yīng)用。在這一背景下，Web 和 Native 如何更好的協(xié)作，如何取長補(bǔ)短，在效率和體驗上能夠進(jìn)一步突破天花板將是長期的挑戰(zhàn)。
智能終端
前面更多談?wù)摰氖?PC 端和移動端，隨著 5G 的完善和普及，IoT 會迎來加速發(fā)展，屆時在移動端和 PC 端兩端之外將會出現(xiàn)更多形式各異的終端，這類終端的 GUI 需求如何解決，是否可以采用 Web 技術(shù)來提效，現(xiàn)有 Web 框架在 IoT 設(shè)備上是否是最佳選擇？隨著 IoT 的爆發(fā)，這些問題會是前端框架不得不考慮的問題。
低代碼化
另外一個看得見的趨勢是低代碼化（low/no code）的普及，不久的將來大量的模式化的 Web 開發(fā)工作極大可能將通過低代碼化的方式來解決，例如運(yùn)營、管理類的平臺就是典型的模式化 Web 平臺，這類平臺在當(dāng)前的前端研發(fā)工作中占有很大的比例，也是當(dāng)前各類前端框架的重要應(yīng)用場景，一旦這類需求由低代碼化的方式來實現(xiàn)，那么具體的實現(xiàn)使用何種框架將變得不那么重要。
在這個背景下，很可能會誕生一些專有框架來更高效的解決低代碼化的領(lǐng)域問題。而通用類框架的場景會更多的集中在非模式化的場景中，在這類場景中對框架的靈活性、定制化等會有更高的要求。
名稱欄目：深入聊聊 JavaScript 框架
網(wǎng)頁地址：http://m.fisionsoft.com.cn/article/dpidcee.html
