我们需要从巨型框架转变到基于组件/库的前端解决方案，但在创建一个行业标准方法有有太多的碎片/抽象。以下是一些建设性想法旨在构建一个更可行和稳定的选择。
可以说,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上公开宣传的“下一个大事件”保持更多的怀疑；目的为了简单,避免不必要的复杂性;保持对话和写作——我们需要讨论他们，我们在一起互相帮助。
