我們需要從巨型框架轉變到基於元件/庫的前端解決方案，但在建立一個行業標準方法有有太多的碎片/抽象。以下是一些建設性想法旨在構建一個更可行和穩定的選擇。
可以說,web前端棧的層,近年來,看到了比其他技術更大的變化速度。
這最初由四個主要競爭的瀏覽器的特性路線圖的積極擴張導致，它們是:Chrome,Safari瀏覽器,Firefox和Internet Explorer。
前端永久革命的時代僅在2008年Chrome打破了Internet Explorer的壟斷時出現，這並非巧合。
JavaScript
前端程式碼三駕馬車CSS,HTML和JavaScript;後者尤其受到不斷變化的影響。多年來,JavaScript漸漸停滯。在過去的十年中,唯一的大發展是採用AJAX（使用XMLHttpRequest物件）的客戶端-伺服器通訊,使用XMLHttpRequest物件,但這個起源於Internet Explorer 5引入的一個特性。
從那時起,JavaScript的擴張步伐在兩個不同的方向。
2009年,監管標準,Ecma International,介紹了他們的第一個新版本,ECMAScript 5,超過十年了。緊接著ECMAScript 6,目前在一些一直佔主流的瀏覽器中有部分實現 ，它將在2015年某個時間完成。 ECMAScript7的公開討論已經在開始.
第二個擴張的區域在HTML5的旗幟下。現在有大量新的api可以使用。在過去的12個月某種程度上,我已經使用了以下幾點: File API; FileReader API; Full Screen API; Cross-Origin Resource Sharing; Page Visibility; Web Workers 和 Base64 encoding and decoding.有幾十個這樣的東西存在,都受到瀏覽器不同程度的支援。
JavaScript框架
對JavaScript強大力量的利用，也見證了前端模型-檢視-控制器(MVC)JavaScript框架的到來。這些框架的MVC架構模式比伺服器端的MVC框架更鬆散，所有變種通常都縮寫為MV *。
第一個在商業上廣泛使用的框架是Backbone.js。由 Jeremy Ashkenas編寫，他也是CoffeeScript的作者,它在2010年秋季首次公開發布。
下面是在12個月間來自Twitter積極反應:
閱讀Backbone.js(http://goo.gl/fELo)和Underscore.js(http://goo.gl/f3VC)讓我想成為一個前端開發人員。
— David Rogers (@al_the_x) June 23, 2011
是的。backbone.js出乎我的意料。這是一些很酷的東西。
— Sean Chambers (@schambers) December 24, 2011
在Backbone.js上花了幾周時間後。我看到一些我很喜歡的模式出現。我認為這可以解決問題
— Simeon Bateman (@simBateman) August 2, 2011
所有這些關於backbone.js的討論。我想我應該參與。你們呢
— Mark Leon Watson (@MarkLeonWatson) August 21, 2011
Backbone.js 是第一個框架，但它的meta-framework（微框架）的方式為新一代的full-frameworks（重型框架）留下了空間。最著名的有Ember.js 和 AngularJS，他們在開發人員中獲得了快速影響,下面是tweets上正面的反應:
晚上玩 @angularjs http://t.co/FHrXSqkv…我越來越愛它!:-)
— Pavol Daniš (@PavolDanis) June 8, 2012
回顧 #JS #MVC #框架，目前angular.js讓我驚訝。找不到任何大的缺點,只有好事:http://t.co/dLIC5pUn
— Adnan Curukovic (@adnanced) March 29, 2012
感謝 #AngularJS 讓#javascript 程式設計也變得快樂：http://t.co/1GKToPZG1D
— Damian Sromek (@DamianSromek) November 25, 2013
使用 #backbone建立一個大型web應用程式?使用 http://t.co/G5G67mzPJy 做所有這一切，或者使用 #emberjs
— Alex Urbano (@asgarothbelem) September 19, 2013
我不必為我的app找一位前端專家, #EmberJS 做了了我需要的一切，而且非常棒:http://t.co/l6ApJRyD
— Guido Cecilio G. B. (@guidocecilio) January 18, 2013
今天,AngularJS的受歡迎程度遠遠超過任何其他框架,儘管Ember.js有一個健康,充滿活力的社群貢獻者和使用者。我認為,2015年將見證 Ember聲望的增加,（因為Angular有爭議的發展路線）。
AngularJS,通常被稱為Angular,由 Adam Abrons 和Miško Hevery最初發起;後來在谷歌繼續該專案。因為它在專案領域和受歡迎程度，更多的開發者自願加入。在2011年的這次訪問中,Miško解釋瞭如何用Angular來建立單頁面應用程式:
Angular 通過ployfill或shim（相容程式碼）的方式為瀏覽器提供構建web應用的有用的詞彙。
許多web應用程式程式碼必須做是通過DOM操作將資料呈現給使用者。DOM操作佔到應用程式大約80%程式碼。Angular允許你宣告的內部狀態(模型)來對映到DOM,這意味著你的應用程式節省大量程式碼。結果是,使用Angular編寫應用程式明顯變短,因此更容易維護。
一般來說,與Backbone相比,使用Angular具有更少的程式碼編寫,儘管這依賴專案的複雜性,這並不一定意味著更少的開發時間。雖然所有主流JavaScript(JS)框架具有很多相似之處,Angular與其他的不同之處在於它使用髒檢查機制,深入的描述可以 閱讀官方文件.
Angular可以追溯到2009年,但絕大多數的Angular開發人員只是在過去的幾年裡使用框架。最初是想為了幫助非web開發人員構建web程式，但是它的複雜性導致它只能是熟練開發人員的工具
前段框架崛起的的一個明顯意外的原因是，伺服器端程式設計師湧入到前端。這些程式設計師帶來這些技術,我認為,更多的web構建方法,尤其在測試驅動開發(TDD)領域和設計模式(儘管他們確實有一些惱人的習慣，比如堅持使用Twitter Bootstrap)。
這不是一篇詳細說明Angular的優點和缺點的文章,但當一個有影響力的新聞刊物如 衛報報導了Angular,這顯然是一個成熟的標誌專案,能夠擴充套件到最高要求的商業環境。
2014年,Angular團隊 釋出關於 AngularJS 2.0的計劃。這個重要的版本將是一個完全重寫的程式碼庫,沒有向後相容性1.x的版本。
增加重要的新瀏覽器功能,比如Web元件指日可待,Angular團隊認為為他們開放是唯一的選擇。這樣一個革命性的路線圖引起許多敵對的聲音,下面的評論來自 Reddit thread。很多評論是由於誤解計劃變更的根本原因而產生,但突出在企業環境中缺乏向後相容性有必要關注:
這是一片混亂。語法看起來像熱屎,這和1.3版本之間的巨大差距，意味著實際工作中存在多年的專案，需要推到。我可不敢告訴我的boss，我寫了一坨很糟糕的程式碼， 我們需要一個定型的編碼方案，也就是沒有18個月就要推倒重寫的新特性。
我在一箇中等大公司工作(2000人),這周推出一個新的web體驗系統來取代所有舊的基於文字的系統。我支援Angular整個工作方法並且很喜歡用它寫的整個UI。這個訊息非常不幸,帶來不便和潛在的昂貴花費。
舊系統已經在不打斷版本的情況下執行了超過15年,甚至從Solaris到Linux的遷移中得以倖存。意味著在他們做出沒有遷移路徑的取前，我甚至不能獲得一年的應用，不現實
不管你對Angular2.0的意見(還有很多好的原因，它應該被完全重寫),這一事件凸顯了企業管理使用一個單一的巨型框架，在時間和資源上的投資風險。谷歌領導的專案已經使用數十名全職開發人員部署在該專案,但谷歌有獨特的業務需求,很難想到一個non-Google-based開源的軟體專案,認為 Dart重要到足以建立一個新的語言, （可以編譯成JavaScript和Dart）AtScript。
這是由一站式解決方案帶來的致命弱點。面臨學習的前景-從頭開始一個新的前端框架(這是什麼,根據目前的計劃,將是Angular2.0),一些聲音已經公開表示，被迫永久革命的前端開發人員已經疲憊。
在倫敦,公司依靠契約勞工。在2013 – 2014年,它幾乎是不可能招聘經驗豐富的Angular開發者,但招聘前景在近幾個月變得稍微好些。
Jimmy Breck-McKye在2014年最後幾周寫一篇文章, 2015 JavaScript狀況
創新是偉大的,但這種生產率似乎過度。當新框架和技術不能保證他們的壽命，不可能讓開發人員付出大的前期時間投資來學習他們。程式設計師想程式設計——他們想創造東西,成為作品的主人。但是我們在花大部分時間學習後，如何做完這些事呢?當我們使用不熟悉的技術在黑暗中摸索時，作為工匠是一種什麼樣的感覺?
Jimmy 提出的一個解決方案是“青睞專業庫而不是整體框架”,因為:
當你選擇一個框架,你做一個大的長期承諾。你開始學習框架的各種內部運作和奇怪的行為。你也簽署了一段無效率時間花費，同時你準備掌握他們。如果框架被證明是錯誤的賭注,你失去了很多。但是如果你選擇各種庫,你可以替代前端棧的一部分而保留其餘部分。
Cody Lindley, JavaScript 啟蒙 和 DOM 啟蒙的作者,在這個問題上通過這兩個微博簡略的表達:
我認為單一的JS應用框架的解決方案對企業最合適是謬誤的。整合為1的JS框架是問題而不是解決方案。
— cody lindley (@codylindley) December 2, 2014
這個概念,單一(所有工具來自一個供應商的支援)解決方案是企業級的是一個垂死的概念。阻止它。
— cody lindley (@codylindley) December 2, 2014
Joe Gregorio的著名的文章， 不再提JS框架, 掀起了全框架和依賴的辯論。我引用了Joe的這句話“零框架宣言”。
構建零框架的宣言
結合幾種不同的非專有許可的軟體專案減輕依賴一個多用途框架的可能性。如果一個元件停止或發展的方向發生了根本的變化,該專案可以相對輕鬆地,被替換為另一個類似的非專有軟體專案。
不過,這種方法有幾種危險。
第一個是機構/公司的坑。有這麼多前端開源/免費專案可供選擇,每個開發的工作室可以構建自己的定製框架。在某種程度上,這是有利的,但是過多的多樣性,特別是抽象——會影響到招聘,保留和培訓員工。
另一個問題是可維護性。程式碼如果不是來自一個可信的源,使用多個專案需對與每個新版本程式碼審查。
如果廣泛採用基於元件的方法,需要遵循共同目標的宣言。以下是一些想法。
1.企業需要給予而不是僅僅拿來。
今天,非專有軟體是大多數企業IT部門web棧每層的核心。所有這些專案面臨的一個主要問題是,企業使用者喜於快速使用基於寬鬆BSD,MIT或Apache2.0許可的軟體,然後沒有貢獻,沒有修改的程式碼的反饋,或者甚至通過部落格或討論分享他們獲得的知識。法律上,在這些許可下,這是他們的權利,但道德上,他們是錯誤的。寬鬆的法律許可,如上面所列的那些,開源軟體可以被解讀為“免費啤酒”,破壞了支撐他們的脆弱的合作式生態系統。
要麼公司需要有一個嚴肅的道德考慮，要麼我們應該放棄寬鬆的法律許可,使用GPL許可證來進行程式碼共享。據我瞭解,這是Richard Stallman主張讓自由軟體不同於開放軟體的最基本分界線。
2。避免過度抽象
通過簡單來達到高效能和可維護性。簡單起見,在本文的框架的討論,意味著堅持Ecma國際標準化的JavaScript規範。 這是版本6的草案。
有一個趨勢是建立JavaScript語言子集,它在執行時編譯成對瀏覽器友好的JS。
React使用JSX，允許框架可以被休閒的開發者比如設計師訪問。Angular2.0將使用ATScript，它將同時編譯成JS和Dart。CoffeeScript只提供語法變化——有點像“給豬塗口紅”。最有趣的是TypeScript,它提供了其他程式語言常見，但JavaScript中缺失的型別,類和介面。
以上列出的4個有3個由三大網際網路公司發起和維護,最初供內部使用，然後通過許可證釋出給所有的開發人員。
ES6指日可待,使用JS子集的吸引力已變得不那麼誘人。
3.使用 同構 JavaScript.
需要有一種雙伺服器端和客戶端解決方案,來啟用鋒利的效能。如果你相信效能在2015年並不重要,我將推薦你閱讀 Tammy Everts的 慢頁面如何損害使用者對你的內容，設計和導航的看法 。
4.清晰的關注點分離
已經習慣於Angular模板中廣泛使用的邏輯擴充套件,現在看來遠比最初顯現的更加自然,當在Angular的介紹日第一次看到內聯JavaScript，我最初震驚了。就像任何平臺,適應並最好地使用功能,但保持邏輯從檢視分離是優先考慮的事。
5.不依賴
任何第三方庫的選擇必須是獨立的,不依賴於另一個庫(雖然“表現好“和“這需要使用”有區別)。
6.使用ES6編譯器。
就我個人而言,我使用ES6到ES5的編譯器會很不爽，像 Traceur 和 6to5. 。他們是“黑匣子”，從一端吃進程式碼，從另一端吐出一個不同的版本,儘管他們避免了使用JS子集,使用標準相容的ES6編寫,然後改為標準相容的ES5,這也在宣言的範圍內。
我在等一個機會接受Traceur或6to5，在一個即將到來的專案之前,我可以恰當地評估它們。
一些庫的建議
下面的列表包含指向一個全燒烤方案的配方部分,它相當於我找遍櫥櫃和冰箱,將我喜歡的原料放在在桌子上。訂閱的格言是“絕對批評現有的一切”,我不不加鑑別地支援這些專案的任何一個,因為他們是進行初步調查的好起點。
輔助功能庫
moment.js:日期和時間的一個有用工具,跨瀏覽器的標準化。
underscore.js / Lo-Dash: 廣泛使用多年,這些庫對JavaScript函數語言程式設計必不可少。我們真的需要一個完整的庫嗎?也許選擇 Mozilla Development Network需要的函式polyfills是更好的選擇。
@andywalpole 寫到:Lo-Dash支援自定義構建,提供單獨的npm包,amd &node模組,es6模組。
— John-David Dalton (@jdalton) January 15, 2015
路由
router.js: router.js Ember.js下使用的微型路由.
route-recognizer: 全面的路由系統識別器 (比如router.js)”.
page.js: 受到Node下著名的Express庫的直接啟發
director: 一個全面的，同構的路由解決方案.請通讀全面的文件和程式碼示例。
Promises
RSVP.js: 一個ES6相容庫，具有“一些額外的玩法”.
ES6-Promise: RSVP.js的子集, 但完全相容ES6特性.
q: 最流行的promises庫，AngularJS使用了它的精簡版.
native-promise-only: 像ES6-Promise，這個專案的目的在建立儘可能地接近原生ES6 Promises的嚴格特性定義的ployfill（注：polyfill：提供了開發者們希望瀏覽器原生提供支援的功能）.
客戶端-伺服器通訊
fetch: a polyfill for window.fetch.
fetch: window.fetch的polyfill.
qwest: 一個基於XHR2的Ajax庫，promises和請求限制.
jQuery:從2.0版本開始，現在可以構建自己的基於JQuery元件的庫，這使得可以建立一個精簡的AJAX為中心的版本。
動畫
cssanimevent: “跨瀏覽器相容庫用來處理CSS3動畫和過渡DOM事件，是不支援瀏覽器的備選”。
Velocity.js:這個js動畫庫,由Julian Shapiro建立，去年獲得了廣泛的關注,現在具有忠實的使用者。
開發助手
LogJS: 一個輕量級的JavaScript日誌平臺.
UserTiming.js: UserTiming 是一個支援所有普通瀏覽器的時間庫的polyfill.
工作流控制/架構
ondomready: 一個AMD相容模組檢測DOM是否準備好了，基於jQuery的ready()方法.
script.js: “非同步JavaScript載入和依賴管理”.
async: 一個全面的非同步工具集合，瀏覽器和node.js都可以用.
Virtual DOM: react.js的一個替代方案. 全面的解釋，請閱讀Virtual DOM 和diffing演算法
Data-binding/Object.observe(): 一年前雙向資料繫結很有熱情，但是一些批評開始出現。Object.observe已經被Chrome支援.
模板
Mustache: 目前最流行的“輕邏輯”模板系統.
微型框架
可以考慮使用微型框架作為起點
bottlejs: BottleJS是一個小巧且功能強大的依賴注入容器.它具有懶載入，中介軟體鉤子，裝飾和乾淨的api，這些啟發來自AngualrJS ModuleAPI和simple PHP library Pimple.
Stapes.js: 一個小巧的MVC框架. 從GitHub的提交可以看到，在過去的一年它沒有收到太多的關注.
soma.js: soma.js是一個工具和設計模式集，用來構建解耦的，易於測試的長效框架. 框架的工具提供依賴注入，觀察者模式，中間模式，門面模式，命令模式，OOP工具和可選的DOM操作模板引擎外掛”.
knockout: 非常流行的，維護非常好的框架，它關注UI介面, 使用Model View ViewModel架構模式.
以上不是一個詳盡的列表，我沒有包含TDD和Web元件
遵循零框架宣言
這裡有一些問題當你選擇一個庫時可以提問:
*這個專案的可維護性如何?如果明天你走了後，別人繼承你的程式碼,他們多快能掌握你的程式碼?
*單個元件影響效能嗎?如果是這樣,他們這樣做是否不必要?這可以通過一個pull-request或fork改變嗎?
*任何不利元件影響可訪問性嗎?這可以通過一個pull-request或fork修復嗎?
*元件開發人員對程式碼的貢獻有多開放?他們是如何快速響應GitHub上問題部分的查詢的?執行一個開放/免費軟體專案可能會非常耗時,儘管許多一開始有最好的目的,大部分很快變得糟糕和失望。
回顧一下:編寫JavaScript,而不是別人解釋JavaScript應該是什麼;使用非專有軟體,但對你拿來的進行回饋,對在Twitter上公開宣傳的“下一個大事件”保持更多的懷疑；目的為了簡單,避免不必要的複雜性;保持對話和寫作——我們需要討論他們，我們在一起互相幫助。