[譯] 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”以避免版權問題)在內的廠商開始嘗試推動並引領了標準化，另一方面瀏覽器的相容性也大量顯現。

由此帶來的後果就是，編寫在不同瀏覽器下都能工作的指令碼複雜而冗長，甚至很多情況下完全不可行。那陣子很多指令碼都只能作為錦上添花的小功能。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 的資料”。

其實 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 以一種不同於 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 關注我們哦