每當 JavaScript 發(fā)布重大更新，我們都(dōu)會(huì)重複相同的經(jīng)曆。最開(kāi)始的時(shí)候，開(kāi)發(fā)人員會(huì)因爲新功能(néng)的發(fā)布而感到高興。他們會(huì)直接使用 JavaScript 編寫代碼，框架的流行度會(huì)下降。接著(zhe)，在較長(cháng)一段時(shí)間内都(dōu)沒(méi)有新的發(fā)布時(shí)，框架就(jiù)會(huì)提供各種(zhǒng)新功能(néng)，從而吸引開(kāi)發(fā)人員。然後(hòu)，再次重複這(zhè)個過(guò)程。

此次的 ES6 據說(shuō)是 JavaScript 最大的一次變化，所以我們又開(kāi)始了新一輪的循環。當 ES6 剛發(fā)布的時(shí)候，框架的流行度下降了，而JavaScript 則變得更強大。但是，我想提出一個更大膽的預測：随著(zhe)開(kāi)發(fā)人員越來越熟悉 ES6 的功能(néng)，最終我們將(jiāng)打破這(zhè)個循環。將(jiāng)來 JavaScript 開(kāi)發(fā)人員不會(huì)再使用任何框架。

我知道(dào)很多人對(duì)此表示懷疑，但請聽我說(shuō)完。我并不是說(shuō) JavaScript 的使用會(huì)變窄，事(shì)實上，如今很多公司都(dōu)在招聘 JavaScript開(kāi)發(fā)人員。相反，我認爲 ES6 的兩(liǎng)個關鍵特性（特别是模塊和類）會(huì)淘汰掉許多流行的框架。換句話說(shuō)，JavaScript 框架都(dōu)會(huì)逐漸消亡，就(jiù)像當年的 Flash 一樣：主要原因還(hái)是因爲沒(méi)有需求了，而且其固有的安全漏洞導緻使用非常危險。
請先不要著(zhe)急爲你喜歡的框架辯駁，讓我來解釋一下爲什麼(me)我認爲會(huì)發(fā)生這(zhè)種(zhǒng)轉變。

JavaScript框架的問題

JavaScript框架是面(miàn)向(xiàng)開(kāi)發(fā)人員的一種(zhǒng)工具，抽象出了前端應用程序開(kāi)發(fā)的一些複雜性。雖然毫無疑問這(zhè)些框架非常實用，但 JavaScript 的 Web 組件規範的進(jìn)步使得即使不使用框架也可以輕松地開(kāi)發(fā)新的前端應用程序（例如單頁應用程序）。那麼(me)，問題就(jiù)來了，使用這(zhè)些框架還(hái)有必要嗎？

讓我們來看看當今最流行的 JavaScript 框架，反思一下它們的不足之處。其實，這(zhè)種(zhǒng)例子比比皆是，因爲如今的大多數框架都(dōu)存在許多根本性的缺陷。

大多數使用 JavaScript 框架的人（我也是其中一位）可能(néng)并沒(méi)有注意到這(zhè)些缺陷，因爲我們已經(jīng)習慣了。這(zhè)就(jiù)像是與魔鬼的交易：抽象爲我們帶來了開(kāi)發(fā)的便利性，但沒(méi)有重視它們帶來的混亂。然而，事(shì)實在于我們使用的大多數框架都(dōu)非常臃腫，它們管理著(zhe) JavaScript 本身并不支持的複雜流程，而且提供的捷徑隻會(huì)讓調試變得更困難。

除了這(zhè)些之外，還(hái)有一個更重要的問題：關于 JavaScript 框架的構成(chéng)，我們并沒(méi)有一個良好(hǎo)的定義。這(zhè)就(jiù)導緻我們陷入了一種(zhǒng)有點荒謬的境地，比如最流行的 JavaScript “框架”之一React 實際上根本不是真正的框架。它隻不過(guò)是開(kāi)發(fā)人員構建的一個高度專業化的 JavaScript 庫。

當前所有流行的框架都(dōu)存在這(zhè)些問題。但也有許多具體的問題隻影響了個别框架。下面(miàn)，我們就(jiù)來快速地浏覽一下。

AngularJS與 Angular

說(shuō)起(qǐ) JavaScript 框架中存在的問題，就(jiù)不得不提 AngularJS，雖然這(zhè)個框架會(huì)過(guò)時(shí)，但人們不一定會(huì)停止使用。許多開(kāi)發(fā)人員仍然會(huì)告訴你 AngularJS 是編寫 JavaScript 代碼的“最佳”方式，盡管該框架已被棄用，而且不花幾年的時(shí)間認真研究就(jiù)很難掌握。

第二個問題是，AngularJS 的代碼幾乎無法理解，而且 Angular 2 也繼承了這(zhè)個問題。雖然有些人認爲這(zhè)是後(hòu)端開(kāi)發(fā)人員收入更高的原因，但實際上會(huì)導緻開(kāi)發(fā)人員的負擔加重。舉個例子，Angular 2 包含區分大小寫的 HTML 實例，這(zhè)不僅違反了 HTML 本身的原則，而且迫使許多人不得不實現解析器，隻爲了清理 Angular 2 生成(chéng)的 HTML。

React
React是另一款非常流行的 JavaScript “框架”，該庫也面(miàn)臨著(zhe)一系列不同的問題。回想起(qǐ)來，似乎 React 的發(fā)展正是爲了應對(duì) Angular 的晦澀難懂。React 向(xiàng)用戶承諾該庫簡單易用。

雖然從某種(zhǒng)程度上來說(shuō)，React 确實做到了，然而問題在于 React 并不是一個真正的集成(chéng)框架，它隻不過(guò)是一組模塊和組件，且無法很好(hǎo)地協同工作。雖然你可以利用 React 實現複雜的功能(néng)，比如實現浏覽器指紋識别，但這(zhè)也意味著(zhe)你構建了一個非常複雜的組件棧，而且必須持續維護和管理這(zhè)些組件。

有人可能(néng)會(huì)指出在 Redux 和 Flux 等系統的幫助下，就(jiù)連初學(xué)者也可以使用複雜的 React 技術棧。但我認爲，如果你需要通過(guò)框架來編寫 JavaScript 代碼，那麼(me)表示你真的有麻煩了。話雖如此，但 React 并不是真正的框架，因此這(zhè)樣的比較不公平。

Ember、Vue 以及Aurelia

最後(hòu)，簡要介紹一些鮮爲人知且使用較少的框架。相信大多數開(kāi)發(fā)人員都(dōu)沒(méi)有過(guò)多地接觸過(guò)這(zhè)三個框架，原因很簡單，這(zhè)些框架的應用非常小衆，并沒(méi)有得到廣泛的使用。

這(zhè)三個框架中的每一個都(dōu)有自己的特質，但是主要問題還(hái)在于應用非常小衆。這(zhè)些框架都(dōu)沒(méi)有達到與更廣泛的 JavaScript 社區建立關系所需的市場份額（盡管根據 StackOverflow 的統計，Vue 目前的受歡迎程度直逼jQuery）。因此，喜歡這(zhè)些框架的開(kāi)發(fā)人員往往需要在讨論的時(shí)候多費口舌。

這(zhè)裡(lǐ)還(hái)需要快速說(shuō)明一下爲什麼(me)這(zhè)些框架都(dōu)沒(méi)有流行起(qǐ)來，尤其是從許多方面(miàn)來看它們都(dōu)是“功能(néng)齊全”的系統。例如，Ember 可能(néng)是三者之中“最像框架”的框架，但它也存在一系列的問題，比如性能(néng)、下載量最大、API 占用空間最大，而且學(xué)習曲線也最爲陡峭。

仔細想一想，你會(huì)發(fā)現一個很奇怪的現象：許多開(kāi)發(fā)人員認爲我們需要一個框架來編寫 JavaScript 代碼，但是當真的有一個完整的框架時(shí)，我們卻更喜歡使用像React 這(zhè)樣的臨時(shí)解決方案。鑒于此，也許我們應該重新評估我們是否真的需要框架。

ES6的前景

上述便是 ES6 發(fā)布的背景。ES6（也稱爲ECMAScript2015）是 JavaScript 的最新版本。它改變了我們使用 JavaScript 的一些基本方式，并引入了多年來社區一直在呼籲的許多新功能(néng)。

雖然你可能(néng)覺得 ES6 的發(fā)布會(huì)導緻各種(zhǒng) JavaScript 框架被淘汰的說(shuō)法很荒謬，因爲 ES6 中所做的更改隻不過(guò)是語法上的調整，但是我覺得重點不僅限于語法上的變化。

這(zhè)是因爲框架提供的大部分“額外功能(néng)”都(dōu)出自同一個目的：通過(guò)改變語法，爲 JavaScript 提供一些捷徑。我們已經(jīng)非常熟悉其中一些語法捷徑，以至于我們將(jiāng)它們視爲單獨的功能(néng)，但其實它們隻不過(guò)是對(duì) JavaScript 現有做法的自動化而已。

我并不是想低估句法創新的作用。事(shì)實上，ES6 中的大部分新特性本質上都(dōu)是語法快捷方式，其中包括：

• 默認參數

• 模闆字面(miàn)量

• 多行字符串

• 解構賦值

• 增強的對(duì)象字面(miàn)量

• 箭頭函數

但這(zhè)些功能(néng)之所以會(huì)加速框架的淘汰，是因爲在它們進(jìn)入 JavaScript 核心之前，隻有框架才支持。因此，這(zhè)些功能(néng)的引入會(huì)減少對(duì)框架的需求。還(hái)有其他的一些功能(néng)（包括 promise 和塊作用域）标準化了我們使用框架實現需求的方式。以前使用不同框架的開(kāi)發(fā)人員如今可以相互交流了。

此外，ES6 的另外兩(liǎng)個新特性則标志著(zhe)框架的終結，或者至少會(huì)暫停 JavaScript 框架的發(fā)展。這(zhè)兩(liǎng)個新特性就(jiù)是實現類和函數的新方式。

類

許多開(kāi)發(fā)人員都(dōu)將(jiāng)面(miàn)向(xiàng)對(duì)象作爲标準，因此多年來一直在 JavaScript 中實現對(duì)象。到目前爲止，我們一直在使用框架和自己開(kāi)發(fā)的解決方案，因爲在 ES5 中類的使用非常痛苦。其實，我對(duì)這(zhè)一點一直非常不解，因爲很明顯 ES5 支持類，關鍵字“CLASS”是保留字。

這(zhè)引發(fā)了很多争論。每個人都(dōu)會(huì)選擇自己喜歡的框架來創建面(miàn)向(xiàng)對(duì)象接口。除了作者本身之外，很難與其他人展開(kāi)合作，而且也無法協同工作。

現在有了 ES6，我們終于有了處理類的标準化方式。ES6 類使用原型，而不是函數工廠方法，如果我們有一個類 baseModel，則可以定義一個構造函數和一個 getName() 方法。

模塊

模塊的情況也大緻類似。事(shì)實上，當發(fā)現 ES5 默認爲不支持原生模塊時(shí)，很多開(kāi)發(fā)人員都(dōu)感到非常驚訝。隻不過(guò)我們習慣了使用AMD、RequireJS、CommonJS 和其他工具實現的變通方法，以至于忘記了這(zhè)些其實都(dōu)不屬于 JavaScript。

現在有了 ES6，我們就(jiù)可以使用簡單的 import 和 export 命令處理模塊了。至少有人會(huì)在一些情況下采用這(zhè)種(zhǒng)方式，但也有人可能(néng)會(huì)再次將(jiāng)目光轉向(xiàng)框架，因爲 ES6 引入模塊的方式真的很混亂。ES6 并沒(méi)有采用 Node.js 處理模塊的方式，但很多人都(dōu)比較喜歡 Node.js 的處理方式。

總結

簡而言之，ES6 爲 JavaScript 帶來了大量的語法變化，大大減少了我們對(duì)大多數框架的需求。再加上我們目前使用的大多數框架都(dōu)導緻 JavaScript 更爲晦澀，而且還(hái)有額外的依賴項。因此，我認爲在接下來幾年中這(zhè)些框架的使用將(jiāng)減少，乃至完全消失。

但也有可能(néng) ES6 也隻是一次曆史重演，我們會(huì)再次使用框架，但在這(zhè)之前我們還(hái)有幾年的時(shí)間學(xué)習如何編寫更好(hǎo)的 JavaScript。