我知道很多人對此表示懷疑，但請聽我說完。我并不是說 JavaScript 的使用會變窄，事實上，如今很多公司都在招聘 JavaScript開發人員。相反，我認為 ES6 的兩個關鍵特性（特別是模塊和類）會淘汰掉許多流行的框架。換句話說，JavaScript 框架都會逐漸消亡，就像當年的 Flash 一樣：主要原因還是因為沒有需求了，而且其固有的安全漏洞導致使用非常危險。

　　請先不要著急為你喜歡的框架辯駁，讓我來解釋一下為什么我認為會發生這種轉變。

　　JavaScript框架的問題

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

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

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

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

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

　　AngularJS與 Angular

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

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

　　React

　　React是另一款非常流行的 JavaScript “框架”，該庫也面臨著一系列不同的問題。回想起來，似乎 React 的發展正是為了應對 Angular 的晦澀難懂。React 向用戶承諾該庫簡單易用。

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

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

　　Ember、Vue 以及Aurelia

　　最后，簡要介紹一些鮮為人知且使用較少的框架。相信大多數開發人員都沒有過多地接觸過這三個框架，原因很簡單，這些框架的應用非常小眾，并沒有得到廣泛的使用。

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

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

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

　　ES6的前景

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

　　雖然你可能覺得 ES6 的發布會導致各種 JavaScript 框架被淘汰的說法很荒謬，因為 ES6 中所做的更改只不過是語法上的調整，但是我覺得重點不僅限于語法上的變化。

　　這是因為框架提供的大部分“額外功能”都出自同一個目的：通過改變語法，為 JavaScript 提供一些捷徑。我們已經非常熟悉其中一些語法捷徑，以至于我們將它們視為單獨的功能，但其實它們只不過是對 JavaScript 現有做法的自動化而已。

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

　　默認參數

　　模板字面量

　　多行字符串

　　解構賦值

　　增強的對象字面量

　　箭頭函數

　　但這些功能之所以會加速框架的淘汰，是因為在它們進入 JavaScript 核心之前，只有框架才支持。因此，這些功能的引入會減少對框架的需求。還有其他的一些功能（包括 promise 和塊作用域）標準化了我們使用框架實現需求的方式。以前使用不同框架的開發人員如今可以相互交流了。

　　此外，ES6 的另外兩個新特性則標志著框架的終結，或者至少會暫停 JavaScript 框架的發展。這兩個新特性就是實現類和函數的新方式。

　　類

　　許多開發人員都將面向對象作為標準，因此多年來一直在 JavaScript 中實現對象。到目前為止，我們一直在使用框架和自己開發的解決方案，因為在 ES5 中類的使用非常痛苦。其實，我對這一點一直非常不解，因為很明顯 ES5 支持類，關鍵字“CLASS”是保留字。

　　這引發了很多爭論。每個人都會選擇自己喜歡的框架來創建面向對象接口。除了作者本身之外，很難與其他人展開合作，而且也無法協同工作。

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

　　模塊

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

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

　　總結

　　簡而言之，ES6 為 JavaScript 帶來了大量的語法變化，大大減少了我們對大多數框架的需求。再加上我們目前使用的大多數框架都導致 JavaScript 更為晦澀，而且還有額外的依賴項。因此，我認為在接下來幾年中這些框架的使用將減少，乃至完全消失。

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