我知道很多人對(duì)此表示懷疑，但請(qǐng)聽我說完。我并不是說 JavaScript 的使用會(huì)變窄，事實(shí)上，如今很多公司都在招聘 JavaScript開發(fā)人員。相反，我認(rèn)為 ES6 的兩個(gè)關(guān)鍵特性（特別是模塊和類）會(huì)淘汰掉許多流行的框架。換句話說，JavaScript 框架都會(huì)逐漸消亡，就像當(dāng)年的 Flash 一樣：主要原因還是因?yàn)闆]有需求了，而且其固有的安全漏洞導(dǎo)致使用非常危險(xiǎn)。

　　請(qǐng)先不要著急為你喜歡的框架辯駁，讓我來解釋一下為什么我認(rèn)為會(huì)發(fā)生這種轉(zhuǎn)變。

　　JavaScript框架的問題

　　JavaScript框架是面向開發(fā)人員的一種工具，抽象出了前端應(yīng)用程序開發(fā)的一些復(fù)雜性。雖然毫無疑問這些框架非常實(shí)用，但 JavaScript 的 Web 組件規(guī)范的進(jìn)步使得即使不使用框架也可以輕松地開發(fā)新的前端應(yīng)用程序（例如單頁(yè)應(yīng)用程序）。那么，問題就來了，使用這些框架還有必要嗎？

　　讓我們來看看當(dāng)今最流行的 JavaScript 框架，反思一下它們的不足之處。其實(shí)，這種例子比比皆是，因?yàn)槿缃竦拇蠖鄶?shù)框架都存在許多根本性的缺陷。

　　大多數(shù)使用 JavaScript 框架的人（我也是其中一位）可能并沒有注意到這些缺陷，因?yàn)槲覀円呀?jīng)習(xí)慣了。這就像是與魔鬼的交易：抽象為我們帶來了開發(fā)的便利性，但沒有重視它們帶來的混亂。然而，事實(shí)在于我們使用的大多數(shù)框架都非常臃腫，它們管理著 JavaScript 本身并不支持的復(fù)雜流程，而且提供的捷徑只會(huì)讓調(diào)試變得更困難。

　　除了這些之外，還有一個(gè)更重要的問題：關(guān)于 JavaScript 框架的構(gòu)成，我們并沒有一個(gè)良好的定義。這就導(dǎo)致我們陷入了一種有點(diǎn)荒謬的境地，比如最流行的 JavaScript “框架”之一React 實(shí)際上根本不是真正的框架。它只不過是開發(fā)人員構(gòu)建的一個(gè)高度專業(yè)化的 JavaScript 庫(kù)。

　　當(dāng)前所有流行的框架都存在這些問題。但也有許多具體的問題只影響了個(gè)別框架。下面，我們就來快速地瀏覽一下。

　　AngularJS與 Angular

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

　　第二個(gè)問題是，AngularJS 的代碼幾乎無法理解，而且 Angular 2 也繼承了這個(gè)問題。雖然有些人認(rèn)為這是后端開發(fā)人員收入更高的原因，但實(shí)際上會(huì)導(dǎo)致開發(fā)人員的負(fù)擔(dān)加重。舉個(gè)例子，Angular 2 包含區(qū)分大小寫的 HTML 實(shí)例，這不僅違反了 HTML 本身的原則，而且迫使許多人不得不實(shí)現(xiàn)解析器，只為了清理 Angular 2 生成的 HTML。

　　React

　　React是另一款非常流行的 JavaScript “框架”，該庫(kù)也面臨著一系列不同的問題?；叵肫饋恚坪?React 的發(fā)展正是為了應(yīng)對(duì) Angular 的晦澀難懂。React 向用戶承諾該庫(kù)簡(jiǎn)單易用。

　　雖然從某種程度上來說，React 確實(shí)做到了，然而問題在于 React 并不是一個(gè)真正的集成框架，它只不過是一組模塊和組件，且無法很好地協(xié)同工作。雖然你可以利用 React 實(shí)現(xiàn)復(fù)雜的功能，比如實(shí)現(xiàn)瀏覽器指紋識(shí)別，但這也意味著你構(gòu)建了一個(gè)非常復(fù)雜的組件棧，而且必須持續(xù)維護(hù)和管理這些組件。

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

　　Ember、Vue 以及Aurelia

　　最后，簡(jiǎn)要介紹一些鮮為人知且使用較少的框架。相信大多數(shù)開發(fā)人員都沒有過多地接觸過這三個(gè)框架，原因很簡(jiǎn)單，這些框架的應(yīng)用非常小眾，并沒有得到廣泛的使用。

　　這三個(gè)框架中的每一個(gè)都有自己的特質(zhì)，但是主要問題還在于應(yīng)用非常小眾。這些框架都沒有達(dá)到與更廣泛的 JavaScript 社區(qū)建立關(guān)系所需的市場(chǎng)份額（盡管根據(jù) StackOverflow 的統(tǒng)計(jì)，Vue 目前的受歡迎程度直逼jQuery）。因此，喜歡這些框架的開發(fā)人員往往需要在討論的時(shí)候多費(fèi)口舌。

　　這里還需要快速說明一下為什么這些框架都沒有流行起來，尤其是從許多方面來看它們都是“功能齊全”的系統(tǒng)。例如，Ember 可能是三者之中“最像框架”的框架，但它也存在一系列的問題，比如性能、下載量最大、API 占用空間最大，而且學(xué)習(xí)曲線也最為陡峭。

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

　　ES6的前景

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

　　雖然你可能覺得 ES6 的發(fā)布會(huì)導(dǎo)致各種 JavaScript 框架被淘汰的說法很荒謬，因?yàn)?ES6 中所做的更改只不過是語(yǔ)法上的調(diào)整，但是我覺得重點(diǎn)不僅限于語(yǔ)法上的變化。

　　這是因?yàn)榭蚣芴峁┑拇蟛糠帧邦~外功能”都出自同一個(gè)目的：通過改變語(yǔ)法，為 JavaScript 提供一些捷徑。我們已經(jīng)非常熟悉其中一些語(yǔ)法捷徑，以至于我們將它們視為單獨(dú)的功能，但其實(shí)它們只不過是對(duì) JavaScript 現(xiàn)有做法的自動(dòng)化而已。

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

　　默認(rèn)參數(shù)

　　模板字面量

　　多行字符串

　　解構(gòu)賦值

　　增強(qiáng)的對(duì)象字面量

　　箭頭函數(shù)

　　但這些功能之所以會(huì)加速框架的淘汰，是因?yàn)樵谒鼈冞M(jìn)入 JavaScript 核心之前，只有框架才支持。因此，這些功能的引入會(huì)減少對(duì)框架的需求。還有其他的一些功能（包括 promise 和塊作用域）標(biāo)準(zhǔn)化了我們使用框架實(shí)現(xiàn)需求的方式。以前使用不同框架的開發(fā)人員如今可以相互交流了。

　　此外，ES6 的另外兩個(gè)新特性則標(biāo)志著框架的終結(jié)，或者至少會(huì)暫停 JavaScript 框架的發(fā)展。這兩個(gè)新特性就是實(shí)現(xiàn)類和函數(shù)的新方式。

　　類

　　許多開發(fā)人員都將面向?qū)ο笞鳛闃?biāo)準(zhǔn)，因此多年來一直在 JavaScript 中實(shí)現(xiàn)對(duì)象。到目前為止，我們一直在使用框架和自己開發(fā)的解決方案，因?yàn)樵?ES5 中類的使用非常痛苦。其實(shí)，我對(duì)這一點(diǎn)一直非常不解，因?yàn)楹苊黠@ ES5 支持類，關(guān)鍵字“CLASS”是保留字。

　　這引發(fā)了很多爭(zhēng)論。每個(gè)人都會(huì)選擇自己喜歡的框架來創(chuàng)建面向?qū)ο蠼涌凇３俗髡弑旧碇?，很難與其他人展開合作，而且也無法協(xié)同工作。

　　現(xiàn)在有了 ES6，我們終于有了處理類的標(biāo)準(zhǔn)化方式。ES6 類使用原型，而不是函數(shù)工廠方法，如果我們有一個(gè)類 baseModel，則可以定義一個(gè)構(gòu)造函數(shù)和一個(gè) getName（） 方法。

　　模塊

　　模塊的情況也大致類似。事實(shí)上，當(dāng)發(fā)現(xiàn) ES5 默認(rèn)為不支持原生模塊時(shí)，很多開發(fā)人員都感到非常驚訝。只不過我們習(xí)慣了使用AMD、RequireJS、CommonJS 和其他工具實(shí)現(xiàn)的變通方法，以至于忘記了這些其實(shí)都不屬于 JavaScript。

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

　　總結(jié)

　　簡(jiǎn)而言之，ES6 為 JavaScript 帶來了大量的語(yǔ)法變化，大大減少了我們對(duì)大多數(shù)框架的需求。再加上我們目前使用的大多數(shù)框架都導(dǎo)致 JavaScript 更為晦澀，而且還有額外的依賴項(xiàng)。因此，我認(rèn)為在接下來幾年中這些框架的使用將減少，乃至完全消失。

　　但也有可能 ES6 也只是一次歷史重演，我們會(huì)再次使用框架，但在這之前我們還有幾年的時(shí)間學(xué)習(xí)如何編寫更好的 JavaScript。