[譯] JS 簡史

原文：https://closebrace.com/articles/2017-09-11/a-brief-incomplete-history-of-javascript

咱們從哪裏開始, 當下在何處, 如何走來, 而且...爲何?

Introduction - 簡介

在2017年，不管是新手仍是滿身疲憊的老兵，都在JS開發中對這門語言掂量着：從何入手以及該選哪條路呢？大夥熱衷於熱門技術，但一般對它們爲何那麼好(或爲何不是別的)並無理解。理解JS的歷史能夠幫助咱們搞清它當今的狀態。

先來聊聊問題。全部語言寫就的全部程序，都在解決問題。在宏觀維度(「如何向用戶交付一個解決方案」)、中等維度(「如何快速有效的排序數據」)，或微觀維度(「怎麼遍歷數組」)上，都在糾結這個。編程語言就是用來讓用戶解決這些問題的工具，而用在web或其餘地方的JS天然也沒有什麼不一樣。有些人樂於細數JS的種種不是，我也不否定確實有不少問題，但對於其餘語言來講也是這樣的。反正我是歷來沒見過哪一個經驗豐富的開發者週期性的抱怨一些早期標準的，由於多說無益嘛。

這篇文章並不會深刻詳盡的着眼於JS解決的全部問題，更非如何去解決這些；而是在一個大的尺度上去概覽歷史 -- 包括語言自己的和其曾用來解決web上不斷增加的複雜問題的方法。要是真的說盡這門語言詳盡的歷史，那足夠寫完一本書了；而本文只嘗試對「咱們在哪？」和「咱們爲何在這？」這類問題給出大致和不失水準的回答，這也是標題叫作「簡史」的緣由。

若是不瞭解當時的基本狀況，就不容易領會「什麼是框架」和「爲何jQuery適合解決A問題而非B」這類常見問題。對這些問題的探索會讓你成爲一個更機靈、有見識的開發者，從而省下大量精力。

這篇文章按四個主要時期劃分：早期時代--新興的語言在瀏覽器中可用的十來年；jQuery時代--當jQuery和其餘框架橫空出世以應對JS開發中一些基礎並頭疼的問題的年代；單頁應用時代--當開發者遇到了jQuery的瓶頸並用Backbone和AngularJS等框架得到顯著提高的年代；現代時代--在此期間，精心編寫的智能化框架大量出現，更關注速度、易用和模塊化，並回歸原生JS。對於每一個時期，將介紹一些當時的web開發的歷史背景和當時人們遇到的問題，並解釋當時的技術如何應對這些問題。

咱們正在自我超越，讓咱們乘坐時光機，回到恐龍制霸地球以及......瀏覽器一家獨大的時代：Netscape Navigator

The Early Era - 早期時代

時間軸: 約在 1996 – 2004
問題: 基本 DOM 操做, 用戶交互
創新: JavaScript自己, XHR 和 AJAX
主要瀏覽器: Netscape Navigator, Microsoft Internet Explorer

JavaScript 是 Brendan Eich 花了十天左右建立出來的, 做爲 Mozilla 的一位員工，他被僱傭來將 Scheme 編程語言引入 Netscape Navigator 瀏覽器中。然而這個計劃被一種語法更接近Java的語言取代了。Eich 創造了 LiveScript，一種能夠直接嵌入HTML文檔並能夠無需編譯就被瀏覽器直接處理的語言。LiveScript 最初在 1995 年 9 月隨 Netscape Navigator 發佈，並在當年 12 月發佈的第三個版本中改名爲 JavaScript。[1]

儘管 JavaScript 這個名字沾了點 Java 的光，但除了有接近C的語法、縮進無關的、面向對象等特性這點兒共通之處外，它既不能和 Java 共享代碼庫，在語言核心方面也明顯是徹底不一樣的。這命名是個商業決定，並致使了接下來的二十多年中，對於 JavaScript 開發者的招聘接洽中充滿了「有大量可用 Java 編程機會」的宣傳...謝謝啊，Mozilla!

在最初幾年中，JS和微軟的幾種腳本語言一決高下，帶來的顯著影響就是，網站要麼在 Netscape 下工做正常，要麼在 Internet Explorer 下(當時發佈了其第三個版本)顯示的不錯，但不能二者兼顧。

無疑，網景公司在這些年一時無兩，看起來不可阻擋。Netscape 3，特別是接下來的 Netscape 4 兩個版本，成爲了其巔峯時刻，它們擊碎了全部挑戰者的下巴。IE 則是個即使 CSS 已經流行的狀況下卻連 HTML 都渲染很差的落選者。

但在21世紀初期，Netscape 的開發失去了活力，而 IE 持續改進(從IE5開始，接下來是5.5，而後是神擋殺神的IE6)，並得到了更大的市場份額。JS的開發在這個時期是有限的 -- 一方面包括 Mozilla 和微軟(把自家腳本命名爲「JScript」以免版權問題)在內的廠商開始嘗試推進並引領了標準化，另外一方面瀏覽器的兼容性也大量顯現。

在 1999 年的 Netscape 4 中 PlanetQuake 的存檔版本。使用了JS在主圖像下滾動新聞標題 ，太厲害了...

由此帶來的後果就是，編寫在不一樣瀏覽器下都能工做的腳本複雜而冗長，甚至不少狀況下徹底不可行。那陣子不少腳本都只能做爲錦上添花的小功能。React Armory 網站的建立者 James K. Nelson 說：「那時爲了給我建的網站菜單欄上增長一個鼠標通過的圖片效果，我使用了JS。並用它建立不那麼好用的下拉菜單和有一些簡單動畫的煩人彈出框」。

討厭的滾動文字、彈出提示、確認框和不少安全驗證充斥着那時的網頁。此外，可能那時最多見的一個JS用處就是建立圖片過渡等 DHTML 效果，其中很大一部分功能後來被CSS取代。

仍是有人在JS領域取得了卓越的成就。《JavaScript: Visual Quickstart Guide》的做者，也是那個時代的開發者 Dori Smith 提到：「90年代後期有大批JS框架和庫，Nick Heinle 和 Steve Champeon 各自有一個具備表明性的。可是這些庫都依賴於做者自己去保持更新，這對任何人，還要同時開發網站的話，都挺困難的」。找到這些庫一樣困難，少有人知。當在web上實現動態交互時，占主導地位的是 Java applets、ActiveX widgets，和 Macromedia Flash。

事情在 2000 年後有了起色，並取得了一些幸運的進展，形成了JS的真正騰飛。衆多成就中的一件事情就是由JS驅動的前端和後端服務器之間的異步通信，包括最終被全部主流瀏覽器接受的 XMLHttpRequest (XHR)。其餘還有稍後出現的一衆開發框架，如 Prototype、 MooTools 以及不得不提的 jQuery。

The jQuery Era - jQuery時代

時間軸: 約在 2004 – 2010
問題: 網站複雜度的增加, 太多的瀏覽器要適配
創新: 健壯的 DOM 操做, 早期的單頁應用
主要瀏覽器: Microsoft IE, Mozilla Firefox

在21世紀初期，DHTML 開始變得流行。D表明着動態，也基本意味着「直接在HTML上搞點什麼，而不用刷新瀏覽器」。這在當下看起來滑稽好笑，但在當時確是個大事情。傳統上，當須要作點什麼時，都須要網站刷新才行。JS提供了一些玩具功能，但標準網站很大程度上仍是基於頁面的。當用戶點擊一個 tab 時，用戶會被帶到一個新頁面，或者是在HTML從新渲染以前調整模板參數變量並刷新整個頁面。

在這個時期中，只有兩種主要的瀏覽器：微軟的IE6--一種發佈時難以置信但最終竟變爲勒住互諒網脖子的行屍走肉的瀏覽器；以及 Mozilla 的 Firefox 。可是也有IE的其餘版本在使用。「由於web標準的貧弱狀態以及大量存在的bug，那時web開發特別困難」，《JavaScript: The Good Parts》(以及其餘不少JS著做)的做者 Douglas Crockford 說道，「自動升級還沒有被引入，因此瀏覽器新版本的發佈並不能消除web上的bug；那只是增長了新的bug」。

嘗試在這些瀏覽器中實現一致的體驗就是一場噩夢；而還想動態的實現這些就是噩夢中的噩夢。jQuery 的建立者 John Resig 在談到該框架的起源時說：

當開始建立這個庫的時候，我想解決本身的兩個痛點: 1) 提供簡單的DOM接口； 2) 減小開發過程當中的跨瀏覽器問題[2]

處理跨多個瀏覽器的DOM訪問是21世紀初web開發者主要面臨的問題，但並不是他們惟一關心的。業界另外一個重磅解決方案就是AJAX，容許和服務器動態交換數據，而非只能依賴於頁面渲染時纔可得到的數據。Crockford 說：「Jesse James Garrett 在2005年發現了 AJAX -- 一個DHTML的新名字；由於 Netscape 已死以及在 IE6 後微軟已經被 web 拋棄，而 W3C 則在徒勞無益的追求語義化 Web，AJAX 取得了遠大於 DHTML 的成功。在長期的忽視後，AJAX帶來了強烈須要的穩定性。AJAX 是一個巨大的成功，鼓舞了衆多庫致力於單頁 web 應用的開發」。

諸如微軟、谷歌和其餘大公司等，做爲早期的先鋒，利用 AJAX 作出了大量激動人心的事情，但直到 2004 年發佈的 Gmail，才真正點燃了 web 開發界。徹底用全新的方式處理電子郵件：所有事情都在瀏覽器中進行，並把郵件儲存在谷歌的服務器上，這意味着用戶能夠在世界各地任何支持互聯網的設備上訪問其郵件，也不用特別安裝電子郵件應用程序。雖然不是第一個單頁應用，但倒是那個時代超然獨立的最好應用，整個世界爲之側目。Gmail 用了一種不多被其餘網站用到的 DHTML 和類 Ajax 的代碼編寫方式，而且還作到了其餘開發者渴望的快速和易用，這些都致使了包括 jQuery 在內的框架的流行。「jQuery 解決了瀏覽器兼容性問題、添加了一堆有用的工具，還引入了比 document.getElementById 更好用的選擇器」，Nelson 說，「其惟一的問題就是過重了，撥號上網時得下載多於 30kb 的數據」。

在 Crispy Gamer 網站上使用了大量的 jQuery。展開框、頭條過渡和切換標籤什麼的

其實 jQuery 也不是第一個，2005 年 2 月發佈的 Prototype 首先被用來爲 Ruby on Rails 開發對 AJAX 的支持，同時也支持 DOM 操做 -- 和後來 jQuery 中廣爲人知的那些差很少。 轉年 jQuery 才發佈，而 MooTools 發佈於 2007 年。這些框架提供了類似的功能，並有各自獨特的實現方法。ProtoType 重寫和擴展了不少 JS 原生的方法，有些開發者會以爲這樣很差。MooTools 更改了 JS 的 Element 對象，也意味着其容許更多的 DOM 操做。

jQuery 並不作以上那些事情，而是聚焦於提供一個以基本的 JS 爲基礎的框架。短時間內這種途徑就被證實很是成功，jQuery 成爲了主流框架；直到如今依然是，2017 年仍是有不少網站仍是基於它而非其餘的框架開發。

這個框架到底提供了什麼呢？先讓咱們來看看這個純JS的代碼片斷，演示了單擊元素時隱藏另外一個元素的邏輯：

var el = document.getElementById('myElement');
var el2 = document.getElementById('myOtherElement');
el.addEventListener('click', function (e) {
  el2.style.display === 'none';
}複製代碼

假如你的瀏覽器支持那些命令，那工做也算完成了，不過當時對於許多 DHTML 和 AJAX 的用例來講這還是不保險的。用 jQuery 實現相同功能：

$('#myElement').click(function() {
  $('#myOtherElement').hide();
});複製代碼

並不僅是更簡明易讀了，還帶來另外的好處：jQuery確保了其在全部瀏覽器中都能工做，而工程師就沒必要花費精力又擔驚受怕了。也意味着開發者沒必要花費一樣多的時間造輪子了。當 jQuery 已經提供了 show/hide/toggle 這些函數時，爲何要本身再寫一遍呢？「jQuery並未真正改變用JS建立的東西」，Nelson 說，「可是確實改變了如何建立的方式。這使得JS在當時以一種看起來很神奇的方式在運用」。簡而言之， jQuery 和相似框架加速並簡化了使用者的開發。

...事情發展到某一天。隨着網站變得愈來愈動態化，以及衆多公司在缺少谷歌那種級別的工程師團隊的狀況下，也以Gmail等爲目標開始構建如此複雜的應用，麻煩就接踵而至了。由成千上萬行 jQuery 代碼組成的大量代碼庫變得難以維護，又包含了很是多的自定義函數，使得新上手的開發者頭疼不已。若是網頁上有5個可點擊的元素，那就有5個 $('#myElement').click() 的實例要管理；若是有500個可點擊的元素呢，麻煩就出現了；若是是5000個元素，可能噩夢就來臨了。

須要作更多的事情了。JS框架開始進化，開始呈現明顯的相似後端的特性和開發方法。單頁應用時代已經到來。

The Single Page App Era - 單頁應用時代

時間軸: 約在 2010 - 2014
問題: 不堪重負的 DHTML, 大規模的數據操做, 速度
創新: 類MVC框架, 雙向數據流, 智能操做DOM
主要瀏覽器: Google Chrome, Microsoft IE, Mozilla Firefox, Apple Safari

還有一些其餘的創新也促成了單頁應用時代的開啓。其中一個就是發佈於 2008 年的谷歌 Chrome 瀏覽器。在谷歌的創新中，包含一組前所未見的強勁開發工具。依靠不斷的改進和升級，這些工具幫助開發者對 HTML/CSS/JS 實時檢視和編輯。還包括了一個智能化的JS調試工具，從而讓這門語言的調試接近於傳統的編譯型語言調試方法(在從前，開發者只能依賴於瀏覽器插件或外部程序作到這些)。如今大部分主流瀏覽器都原生提供了相似的能力。

說到谷歌另外的貢獻，V8 JavaScript 渲染引擎是其中一個，正是其爲 Node.js 這類JS獨立運行平臺的出現創造了條件。本文主要聚焦於JS前端的歷史，可是若是不說起在網站開發中已經成爲一種主要因素的 Node.js 的話，那就是咱們的失職了。因其快速、異步實現的特徵，在開發者中大受歡迎，不管是業餘愛好者仍是大公司都普遍採用；不少網站都由 Node.js 驅動。

在單頁應用時代，並不僅是 Chrome，其餘瀏覽器都比其餘時期更平等的被使用，這對開發是某種好事。即使是 IE 這樣的瀏覽器，也從善如流的愈來愈擁抱標準。首次來到了一個有可能不管在哪一個瀏覽器上打開網站，看起來和用起來都同樣 -- 頂多有點細微差異的時候。Sass 等 CSS 框架也出現了，這簡化了 web 開發的視覺方面；另外對於盒模型的限制也已經被徹底整理出來(致使了一系列關於有多少所謂 Web2.0 網站看起來雷同的討論，有些廣爲流傳，有些不爲人知)。flexbox即未來臨，Ethan Marcotte 在 2010 年發表了他的關於響應式網頁設計標誌性文章，但過了好長一段時間，該技術看起來才比較穩定了。

在單頁應用的世界裏，狀況沒那麼複雜了。由於疲於應付成千上萬行 jQuery 代碼形成的亂局，開發者們開始另尋他法。和上一個時代的框架更關注 DOM 操做以及基本 AJAX 問題不一樣，新一代的框架被開發出來 -- 爲了管理複雜程度日益增加的應用而提供一整套工具。這些 JS 框架多有借鑑，好比 C++, PHP, Ruby 等後端語言中已經存在的那些。

2010 年，開發者 Jeremy Ashkenas 向單頁應用開發者們發佈了 Backbone.js。輕量、快速，而且不依賴於 jQuery (固然開發者們仍是能夠藉助 jQuery 使用更多 Backbone 的特性)，Backbone 被用來應對 「jQuery 沼澤」問題。其網站上的這段文字是這樣闡釋的：

「採用 jQuery 的選擇器和回調建立 JS 應用確實簡單，但終將陷入一團亂麻；你將手忙腳亂的保持數據在 HTML UI 和 JS 邏輯，以及服務器數據庫之間的同步。對富客戶端應用來講，更結構化的方式纔是更好的」

Backbone 的辦法是將代碼劃分爲數據模型類、操做這些數據的函數集合、顯示它們的視圖類；還提供了一些幕後自動處理的方法。藉助於數據和視圖的鏈接，當數據改變須要網站隨之更新的時候，開發者就無需過於操心了。Backbone 做爲一個卓越的產品，獲得了普遍的應用，不少知名 web 應用都由它構建。

一樣在 2010 年，AngularJS 的首個版本浮出水面。初始開發者是 Miško Hevery 和 Adam Abrons，而且在 Hevery 被谷歌僱傭後，該項目也落入這家公司之手。通過谷歌和不少奉獻於此的外部開發者的持續支持，最近發佈的 2.x 版本通過了顯著的重寫並確實進化了一代。而 1.x 版本仍被谷歌和開發者們支持，並普遍應用於互聯網。

用 AngularJS 寫成的 To-Do list -- 這個時代中應用界的 「Hello World」

AngularJS 以一種不一樣於 Backbone.js 的方式提供了一整套前端結構方案。它提供了強有力的工具和一個基於組件的結構，這用 jQuery 是很難或者是不可能搭建起來的。Nelson 說：「數年來我在嘗試用 jQuery 和純 JS 搭建好用的單頁應用的過程當中屢戰屢敗，直到我偶然發現了 AngularJS，它教會了我應用模型不用糾結在 DOM 中。這使得大型應用的運轉成爲可能」。

使用了雙向數據流概念的 AngularJS，容許開發者構建同時在服務器端和客戶端反映數據變化的應用。舉例來講：你能夠建立一個 AngularJS 應用，讓用戶填寫表單的時候，實時在頁面的其餘地方看見正在輸入的數據，而且獲知這些數據也同步保存到了服務器。切實的改變是，不用爲了達成這類同步再寫大量 jQuery 代碼了。

和 Backbone 相似的是，AngularJS 提供了不少操做 DOM 的輔助工具。一樣相似的是，也能夠很好的結合 jQuery，但並不須要 jQuery 去承擔不少主要功能。這就方便了熟悉 jQuery 生態的開發者逐漸遷移到 AngularJS。

該框架同時也促進了對使用組件的普及 -- 用來呈現 HTML 標籤且包含了複雜邏輯的獨立函數。這提供了更整潔、劃分更清晰的標記；能夠像下面這樣用標籤調用一個組件：

<userlist ng-repeat="user in $user.list"></userlist>複製代碼

這段代碼生成了一個完整的用戶列表，包含豐富的細節，並內嵌了諸如跳轉到用戶詳情頁的連接等 HTML。一樣重要的是，若是數組 $users.list 中的數據變化了，AngularJS 就會自動根據更新後的新數據自動從新渲染列表，而無需開發者的干預。

有了 Backbone 和 AngularJS，開發者一晚上之間就擁有了兩個用來開發單頁應用的完整工具箱，能夠應對以前大規模 jQuery 開發中的短板，並繼續用熟悉的方法開發。若是把 JS 比做基本手邊工具，而 jQuery 是電動工具的話，那這兩個框架就能夠說是流水線了 -- 專業集成了爲建立單頁應用這個特別目的設計的複雜設備。

問題在於...它們都算不上小巧和快速(特別是在移動設備上)，這可能會使其難以維護，而且整個雙向數據流機制也可能變成一把雙刃劍。

Facebook 在 2013 年發佈了 React，一個小巧和極速渲染的前端框架。隨後其又在 2014 年發佈了其基於事件的應用管理和開發工具 Flux。這些產品以及圍繞其成長的相關技術，再一次改變了 JS 應用開發。

The Modern Era - 現代時代

時間軸: 約從 2014 至今
問題: 速度, 增加的應用複雜性, 可靠性
創新: Virtual DOM, 單向數據流, 強類型, 測試
主要瀏覽器: Google Chrome, Apple Safari

在過去的幾年，網頁的訪問方式發生了深入的變化。曾經是家用 PC 獨佔的網站訪問領域，如今變成了手機、平板電腦、筆記本電腦，以及臺式機並存的狀況。這些設備的帶寬、處理器能力以及可用的屏幕分辨率各有不一樣。少許下載和快速渲染變得特別實用...你所熟悉的用大量圖片下載、幾兆幾兆的廣告代碼、自動播放的視頻等來打動用戶的做法已通過時！

和用戶的期待不一樣的是，不少內容網站還不是單頁應用。單頁應用被用來替代原生應用，在速度和響應能力方面也被寄予和原生應用一樣的指望。用戶也許能忍受用 5 秒鐘加載一條最新的體育新聞，但很難作到花一樣的時間在銀行應用程序或分析監控面板裏去等待點擊按鈕後的響應。

Facebook 爲其開發者們發佈了 React，以便迅速易用的進行開發。不少人的努力和智慧凝聚其中。它並不是完美，還有更新更好的後來者層出不窮，且雖然它爲開發者提供了不少東西 -- 而其中不少用到的東西其實並非項目中真正須要的...但咱們仍會從中獲益。

React 並非做爲 JS 框架替代 Backbone 和 AngularJS 的，雖然確實削弱了它們；部分緣由是 React 並非一個完整的框架。React 初期主要被構想成一個 MVC 框架中的視圖層語言。儘管不少其餘自定義技術也是由 Facebook 開發的，但它確實能夠結合各類既有技術；換句話說，對非 Facebook 的技術一視同仁，React 不處理數據、不處理事件、不處理 XHR/AJAX ... 所作的就是渲染組件。

在閱讀本文時，極可能你已經據說或正在使用 React 做爲整個前端的解決方案了。爲何會這樣？由於藉助 Webpack 或 Browserify 等打包技術，整個生態圍繞 React 生長，使得 "React" 其實是 "React 加上一整套的其餘東西" 的簡稱。Nelson 簡短的總結爲：「在某種程度上，會感受所謂現代時代很像 jQuery 時代，構建單頁應用垂手可得，從而不必去搞新類型的應用。React 用更簡單的方法建立可重用組件；Webpack 和 NPM 促進了那些組件和其價值的分享；而 Babel 意味着咱們不用建立新語言，用 JS 就行了」。

無論怎樣，React 也仍是存在其問題。基於打包的生態意味着若是不付出不少努力，JS 文件尺寸將迅速失控。即使對於資深開發者，要掌控全局也不那麼容易，更甭提新手了。高質量的文檔和友好的社區會緩和這些問題，但學習曲線依舊陡峭。

其餘框架也雨後春筍般的出現。AngularJS 2 借鑑了不少相似 React 的方式大幅重寫了其功能；其渲染速度大大優於版本 1，尤爲在顯示大量數據時。早於 React 至少一年發佈的 Meteor (事實上，也能夠用 React 做爲其視圖層)， 也有本身的擁躉。最先在 2014 年發佈的 Vue.js，是一個小巧快速的前端框架，能很好的結合其餘技術；其語法相似 React，其結構也是相似的基於組件的實現，雖然不是如出一轍吧。Preact 也是一個極小而快速的 React 替代品，它基於日益廣泛使用的 ES6 -- 一個日益廣受歡迎的更現代化 JS 版本(React 一開始用差很少已經被熟知了十年左右的 ES5 構建，也能夠用 ES6 工做)。此外還有一些其餘框架。

須要特別關注的是 React、AngularJS 等所作的事情，並非在重複造輪子。「沒人再提 DHTML 或 AJAX 了，人們都開始說單頁應用，但實際上是新瓶裝舊酒」 -- 這很大程度上是對的；基礎代碼還是 JS，也仍舊幹着早期的事情。不一樣一點的是今天的實現途徑。

全部這些框架都傾向於解決相同的問題：建立不少工具方便開發者快速構建，以使單頁 web 應用能很好的工做於多種設備上。它們很注重數據流和顯示：基本上，對於取得終端用戶所需的顯示數據，並在數據變化時自動更新顯示這部分工做，減輕了開發者必須的工做量。當處理海量數據，而且想給用戶提供相似應用的體驗時，這些框架真的是能救命啊。

下面說說 Vanilla JS。當前，你可能想知道若是某人在開發一個只需很少 JS 的小網站該用什麼呢。AngularJS 和 React 看起來都是殺雞用牛刀，是吧？

確實是。當你只想監聽幾個按鈕以及切換 tab 的時候，用大量現代 JS 框架組成的好得很的單頁應用就過於複雜了。"我該用什麼？"的答案就是：取決於具體的需求，用 jQuery 或 Vanilla JS 均可以。

Vanilla JS 可不是一個框架，也不是一個庫，其實什麼也不是，就是 JavaScript。最近的更新已經使 JS 至關易用了。好比document.querySelector 和document.querySelectorAll，用相似 CSS 的語法提供了類 jQuery 的元素選擇(好比 ".exterior-link")。ES5, ES6, 和 ES7 基本上已經被現代瀏覽器所支持；老舊瀏覽器正迅速減小，對於那些再也不受制於此的用戶，就下降了藉助 jQuery 跨瀏覽器的須要。從性能考慮，書寫純 JS 代碼幾乎確定會更快(除非你的程序不優化)，即使是在更老更慢的設備上。和不少開發者同樣，Smith 對這種新關注點很興奮：「我從 Vanilla JS 得到了不少回報。我已經完全厭煩了 Stack Overflow 那些濫用 jQuery 和其餘框架的傢伙。引入 jQuery 就是爲了把本來 3 行代碼能解決的問題寫成 5 行嗎？」

因此，在當今，2017年，JS 生態系統繁榮而混亂。沒人能預測前方的狀況，持續生長的只有變化。web 裹足不前也就意味着 JS 的止步，咱們也很期待將來時代能帶來什麼。但願你能以爲本文有趣又有益，而且更加留意咱們在何處、咱們如何來到此地，以及爲何咱們選擇了這條路。感謝閱讀。

-------------------------------------

長按二維碼或搜索 fewelife 關注咱們哦