同作为JavaScript MVC框架，Backbone和AngularJS各有什么优缺点？
按投票排序
写了这么多AngularJS代码，可以说我对AngularJS了解比较深入了。Backbone也是一个很热门的JS框架，我通读了一下它的API文档，大概了解了他的运行机制。Backbone很精巧，很强大。但对比AngularJS，我说说我看到的Backbone的缺点，由于接触时间短，可能会存在误解，见谅。Backbone的Model把服务器端的数据模型映射到浏览器端，绑定数据验证机制，并与相应的REST操作绑定，这样每个数据模型都变成了独立体，方便REST操作，却限制REST的灵活性。比如我要将10个todo批量标记成已完成，它会发出10个REST请求。Backbone的Model没有与UI视图数据绑定，而是需要在View中自行操作DOM来更新或读取UI数据，这点很奇怪。AngularJS与此相反，Model直接与UI视图绑定，Model与UI视图的关系，通过directive封装，AngularJS内置的通用directive，就能实现大部分操作了，也就是说，基本不必关心Model与UI视图的关系，直接操作Model就行了，UI视图自动更新。而Model数据验证、与服务器端的数据交互都是非常简单而自由的。AngularJS的directive，你输入特定数据，他就能输出相应UI视图，这样的directive可以变成了一个html通用组件，比如文章编辑器组件、分页导航组件、madal组件等，在不同应用中可以直接拿来用，减少重复开发。我想，Backbone大概很难实现这样的通用组件。Backbone的View没有把html与JavaScript解耦，要控制UI视图，实际上就是用JavaScript控制DOM，或者通过第三方模板引擎控制HTML字符串，而这些，都需要程序员在代码中用JavaScript自行实现。AngularJS不同，写UI视图就是写正常的HTML/CSS，写逻辑控制代码就是用JavaScript操控数据（不是DOM），不同的就是增加了directive，实现DOM与数据的互动，如上所述，directive是通用组件。AngularJS只是定义了一个环境和一个数据与视图交互的机制，并提供了若干通用组件和服务，所以AngularJS开发很简单，很高效，很“原生态”。虽然我没有真正写过桌面应用程序，但我觉得AngularJS的理念就是把WEB当作应用程序来写——Web App。反观Backbone，对于数据与UI视图的互动并没有大的改进，仅仅提供了数据变更事件通知，它侧重于REST数据交互了，而REST数据交互本来是很容易处理的。注： 使有用Backbone，以上内容也算我与teambition团队的一次交流，有关注Backbone的同学可以可以与他们交流
问题好大，简单的说说折腾的感受吧。至于优缺点，其实是双刃剑吧。# Backbone## 轻量、随性可以更自由的和其他类库搭配使用，不太要求特别固定的模式，但要实现完整应用，需要写更多代码或者三方库的依赖。Backbone's only hard dependency is
( &= 1.4.3). For RESTful persistence, history support via
and DOM manipulation with , include , and either
( &= 1.7.0) or .—— # AngularJS## 功能全面更快的开发，unstable 版本带有 angular.mobile ，开发移动应用也就多引用个很小的 js 文件（夸张了，不过这个直接把 ng-click ng-mousedown ng-mouseup 等换成了 touch 事件，省去了很多事。）而且，自带了一个 jQLite，常用的 DOM 方法可以同 jQurey 那样使用。在 directive 的自定义中使用非常多。虽然块头更大，但能写更少的代码。## 模式化.value(name, value)
.constant(name, value)
.factory(name, providerFunction)
.service(name, constructor)
.provider(name, providerType)
让人很容易联系到设计模式里的东西。用上面这些建立好不同的模型或者方法库，以供 .directive 和 .controller 使用。function TestCtrl($scope,name) {};
## directive不得不说这是 AngularJS 的一大特色， 用自己想用的任何方式来构建 HTML，而且高度复用。更多参考：## 填料箱虽然提供了不错的模式，但是依然允许混搭。自由度虽然也有，但是否利于维护就不好说了。比如首页给的这方式，function TodoCtrl($scope) {};
直接这么写，压缩的时候就得报错了。除非：function TodoCtrl($scope) {};
TodoCtrl.$inject = ['$scope'];
或者（用于模块化开发，参考
的源码）angular.module('appModOne',[])
.controller('TodoCtrl',['$scope',function($scope){
相比从全局里去找接口，用 AngularJS 给的这些方法管理更方便点。## 兼容性部分方法 IE 不支持（嗯，又是 IE），比如这样还有别的，其实都差不多了。感觉上。AngularJS 写得挺多，也许是折腾的时间比 Backbone 长吧，更多关于 Backbone 由前辈们补充吧。总之，这两者都颠覆了我对前端的理解。还是有太多的东西要折腾。
关于这个话题，我知道大家说的也累了，随便上几张图吧：--------------------------------------------------------------------------------------------------------------------------------资料摘自：
很多人觉得AngularJS要先进于Backbone，我不认同。Backbone正如他的名字-”脊椎“，他是一个小巧灵活的库，是个不错的工具，适合那些有一定Web基础，喜欢原生JS，自己去操作DOM（因为它没有DOM Binding），写一些框架、库、插件的童鞋。它的特点是灵活，并不全包。只是帮你实现一个MVC模式的框架，更多的还需要自己去实现。但是我并不认为这是落后。而AngularJS，真的很强大，可以方便我们快速开发大型Web APP。他的很多概念（比如双向绑定、依赖注入等），也很流行。因此，我更习惯称作它为一个工具集，它把什么都给你”承包“了。是的，你专心写逻辑就可以了。很适合快速搭建应用，学习曲线也较为平缓。但是问题是，你要受制于整个框架。如果你觉得你的程序，使用AngularJS完全可以实现，那么AngularJS确实可以帮你省很多力气。Backbone工具，AngularJS（Ember.js）工具集。看你的需求。
首先 Backbone 没有 AngularJS 那么容易上手. 而且作者并没有想让Backbone草根化的意思.Backbone 比喻成战斗机. 看上去更像是真正的MVC框架, model-views-controller(collection).书写Backbone的时候模型, 集合数据, 视图都是分开的, 逻辑很清晰. js模版的好处自然不用多说.Backbone实际上是 (( 为了去除掉以往 jQuery 过分依赖DOM来写业务逻辑, 导致后期代码逻辑混乱,DOM和JS上紧耦合. 函数内部层层调用, 甚至还会出现各种夸多个文件层层调用.使得业务最终变得难以维护,越来越臃肿,功能耦合度越高.修改起来就越容易导致其他功能出现难以预料的BUG . )), 而Backbone则很大程度上解除DOM和JavaScript的耦合关系. 更接近MVC的真谛. 但是Backbone只提供基本的工具. 没有进行更加复杂的封装.Backbone 的优势 : 体积小, 制定性很强.提供underscore工具函数, 按照每个程序员不同的Style来处理数据, 或者你自己封装提供自定义模版引擎, 也就是说, 你想怎么渲染, 就怎么渲染提供完整的RESTful 风格API.想怎么写就怎么写. 模型 , 集合, 视图分离. 逻辑清晰. 只要是个稍微懂规范的程序员, 都可以写出不错的逻辑结构. AngularJS 比喻成坦克.
看上去更加像是弥补HTML构建应用的不足(官方自己这样描述的).把JS逻辑和HTML标签紧密结合在一起, 通过依赖注入, 来实现开发模块化. AngularJS的确提供了很多的遍历, 封装了很多复杂逻辑, 双向数据绑定. 逻辑区域划分. 所以它是重武器.------------------------------------- 插入 写在这里 -------------------------------------------Pass :
关于Google 为什么力推 AngularJS? 而不推MVC的鼻祖Backbone
首先是兼容性方便, Backbone 坚持支持IE6以上的浏览器, 原则就是希望大部分浏览器都可以跑Backbone. Angular 在这方面就截然相反了. Angular 由于库本身非常庞大, 模块很多, 为了不让库变的臃肿, 在 AngularJS 1.3 之后就不支持IE9以下的浏览器了( IE9上也有很多问题 ). 也就是说, AngularJS 开发就是针对一些高端的APP. 高端的应用, 换而言之, 一般来说 一些懂一点电脑的用户都知道升级浏览器, 而其中Google 的体验最好.所以Google 首先力推Angular , 你看不了网站, 被提示版本过低,要么不以后都不看, 要么你会选择升级浏览器, 或者换浏览器, 我想大多数都会升浏览器.AngularJS 对一些技术含量比较低的搜索引擎来说非常不友好, 没有什么原因. 像Google 的搜索技术已经摇摇领先全世界了, 而且爬虫可以识别JS渲染之后的数据. 这也是为什么Google力推Angular的原因之一/------------------------------------- 小段结束 -------------------------------------------AngularJS 的优势:容易上手, 必须了解依赖注入少量代码就可以完成双向数据绑定. 自动同步改变数据. Backbone需要自己手动和HTML结合在一起写逻辑. HTML结构有清晰的划分. 脏值检测. 不依赖其他第三方库1.Backbone 和 AngularJS 比实际上主要优势是在移动端，还有它的兼容性， Backbone 组合兼容IE6 - IE11 后现代浏览器都没问题。 AngularJS 撑死就兼容到了IE8，还有很多功能在IE8上都有问题。 而且AngularJS通过对标签添加自定义属性 和 混入模板 来执行操作。所以对于搜索引擎而言， 非常不友好， 无论你是通过混入模板的方式 如{{ item.data }}
还是通过自定义属性 ng-model = “item.data” 来给你标签绑定模型。搜索引擎都无法读取到你标签内部真实渲染后的数据。而读取到{{ item.data }} 这样的模板.(大多数爬虫都是忽略掉页面js的影响的.) . 对SEO很不利。2.Backbone 和 AngularJS 体积上来看， 并没有什么优势可言，（不算站点开启了gzip） 一个表面上压缩过的AngularJS 大概是101k -120k （没有压缩的开发者版是800K以上，1.2.X版本）. 不需要依赖什么其他的js库。而Backbone 依赖 Underscore.js
压缩后 Backbone + Underscore = 20k + 14k = 34k ～ 36k的样子。 别高兴的太早的， Backbone 还需要引入一个核心库。类似于jQuery这样的。 PC开发时，引入一个压缩过的jQuery1.11.1 是101k～105k，不兼容IE6 7 8 引入压缩后的 jQuery 2.0以上版本是 89K ～ 94k。 所以大小加起来 Backbone + Underscore + jQuery = 130k ～ 145k 。如果是移动端的开发，不需要引入jQuery ，而是使用Zepto的话。Backbone组合的大小就骤降到了 44k～50k. 这个时候Backbone在移动端的优势就体现出来了。而这样一来. Backbone + Underscore + jQuery(or Zepto) 就比一个AngularJS 多出了2 次HTTP请求.3. 这里注意一下, Backbone自己描述是非必要! 非必要!依赖jQuery 和 Zepto. 实际上它没了jQuery 它的View视图就会各种出错, 所以说白了, 他自己就跟jQuery绑在了一起. 要换其他DOM库你还得自己操作,老版本的Backbone还根本就没有提供你改库的权利.Backbone 表面说不依赖jQuery. 实际上.... 呵呵, 你懂的, 没有jQuery你视图怎么绑定在DOM上? el 根本就不支持类似于 document.getElementByxxxx这样的获取DOM节点.所以我想说, 你如果不想在项目里搞太多库, 找AngularJS. Backbone进去了你就必须用个jQuery!如果有Ruby开发经验的人就知道, Backbone实际上是把Ruby on Rails给放到前端来了,Ruby程序员对Backbone的结构会是再了解不过了.1.Backbone的实例非常少.冰山一角.2.Backbone是一个Framework,而不是个Library.3.Backbone只提供了工具函数 small、simple、flexible , make sense. 也就是它和jQuery不太一样的地方,不是"write less , do more"4.Backbone并没有减少代码的编写量,用不好反而增加不少工作量, 一个原本看似简单的功能,用Backbone现实起来看起来总感觉会很别扭. 所以用不好的人就是会"write more. do less"5.Backbone能不能发挥它的极致完全取决于使用者的水平, 所以作者对FrameWork理解是: "a framework calls you, you call a library"对于一个新手而言, 不具备一定的原生JavaScript功底是很难驾驭Backbone, 仅仅局限于会用几个$符号来是完全不能理解Backbone的哲学的.Backbone到目前为止都没有完整的中文文档, 之前有个人翻译了0.5版本的中文文档(基本可以说他没有翻译...), 但是目前Backbone已经是1.0版本以上了. 比之前新增了不少的功能.
可以说, 想学的人,就算你看得懂英文, 看得懂API, 没有实例, 你也不知道怎么样应用. 市面上的书籍也非常少.\而能把Backbone发挥到极致的, 一般都是老外, 比如说,著名的USATODAY就使用了Backbone. 你很难想象一个全美大型的新闻网站是一个Backbone打造的SPA (注: SPA在国外的应用已经非常普遍了, 见怪不怪,反观国内Web技术可以说还是落后人家5-6年)从 Backbone在GitHub 上的18258个Star就足够证明它在国外的地位. (注: 08年入驻GitHub. 非常深厚的原生JavaScript背景.)反观 AngularJS , 中文文档不少, 网上也有不少实例, 上手较Backbone来说要容易一些. 而且AngularJS 没有必要强制依赖其他库.而Backbone本身就依赖作者 自己开发的另外一个JS工具包UnderScore 可以说你想要学好Backbone, 就不得不去了解和学习UnderScore. 而UnderScore总共有60多个针对数组,集合,函数操作的Method. 只有在项目中实践了才可以说真正理解了UnderScore的用途. 这也造成了 Backbone 学习曲线陡峭, 尤其是对于那些本身对MVC就不了解的新手来说, Model, Collection 理解起来可以说是晦涩难懂.
个人观点，仅供参考他们都是为解决代码组织而生的框架当你写了一个几千行以上代码js单页面后就会自然的感觉到代码组织，比代码实现更加的重要.-----backbone是完全按照mvc思想设计的，并没有什么约定俗成的概念，这是我觉得backbone最大的优点和缺点。你可以用任何东西来与这种思想集成，更接近原始的概念，就是以数据和操作流程为代码设计核心。用户修改了输入框的内容，好更新其中的一个变量，变量有update事件，事件注册到好几个地方。缺点也很明显，就是除了mvc一切都得你自己去实现，自由度很高，开发效率有很大的提高的空间，emberjs就是这样的框架，它集成了很多需要的功能也制定了很多惯例，降低了自由度却很大的提高了效率。由于backbone 设计的view太简单，如果项目大量dom 操作推荐加入viewmodel ，reactjs vuejs都可以angularJS：angularJS一出生就有两个目的：开发大型高交互程序，提高开发效率。它引入了很多概念，我认为更像是compnent，但以数据和操作流程为代码设计核心这个核心概念，仍然是angularJS的设计基础总结：如果你想要自由度，或者项目本身的复杂度并不是很高，不是以数据和操作为主导的，更多的是页面设计的东西，或者你想将已有的代码集成mvc组织结构，backbone。如果你一开始就是要设计一个单页面，且复杂到像c/s架构一样的程序（gmail），你可以提前放弃backbone了，开发效率是个问题。虽然，我是支持angular的，但是我还是会在许多前台页面中使用backbone，甚至只使用underscore.js，原因很简单，没必要。至于更复杂的应用，我往往使用extjs，而不是angular。
读过两者的源码，各做过一小项目。backbone简单，明显没有bug。angular庞大，没有明显bug（我做项目的时候遇到了好几个bug）。我说backbone简单，是贬义的，它只是提供了核心的玩意，要完成项目需要的其它很多很多东西它都没有，需要另外找解决方案，烦死了。我说angular庞大，是褒义的，它提供了要完成一个项目所需的几乎所有东西，用angular就可以，不用再找别的。但是，angular有一个致命缺点：它几乎无法与别的方案并存，往往必须angular到底。（这是由angular独特的模板系统决定的。）猜想这也是angular庞大的原因。所以，如果项目的需求都可以用angular解决，那么我会推荐angular。我不喜欢angular的模板，如果有什么框架是把angular的模板剥离掉，而剩下 routing / DI / $q等等东西，我会很喜欢。backbone能做的事情虽然做得很好，但它做的事情实在是太少了，给我感觉是“上个世纪”的技术，除非已经用得很熟，否则还是尽量考虑别的方案吧～比方说：当然，backbone跟react也是可以一起使用的。
以从零开始学习MVC的角度，个人觉得Backbone优于Angular。小菜鸟一枚，抱着了解MVC的心态去学习Angular，一段时间后进行不下去了，因为让你分心的概念太多了。反观Backbone，看了没几天，各层结构清晰，目标明确，真是太舒服了。Angular虽然大而全，但屏蔽掉了很多细节，虽提高了开发效率，但个人觉得觉得，抱着学习的心态，如果觉得自己js底子还可以，还是应该从Backbone开始，对理解MV*的帮助明显高于Angular（个人感受）。就像你刚开始学js时，应该不会有人建议你直接用jQuery吧。（比喻不当好像不太恰当，但大概就是这意思）
分享一篇国外某coder写的对比文章吧，写得很不错！个人感受，没有最好的，只有最合适的！截几张图：当前访客身份：游客 [
已有文章 2117 篇
当前位置：
AngularJS 、Backbone.js 和 Ember.js 的比较
英文原文：
0人收藏此文章,
推荐于 1年前 (共 18 段, 翻译完成于 08-26) ()
参与翻译(2人)：
我们准备在这篇文章中比较三款流行于Web的“模型-视图-*”框架：AngularJS、Backbone和Ember。为你的项目选择正确的框架能够对你及时交付项目的能力和在以后维护你自己代码的能力产生巨大影响。你也许想基于一款可靠的、稳定的和成熟的框架来构建项目，但又不想为此受到约束。Web发展迅速——新技术产生，旧的那套方法很快跟不上潮流。如此形势之下，我们准备仔细深入的比较这三个框架。
&翻译的不错哦!
2& 框架概览
今天我们提到的所有框架有许多共同点:都是开源的，遵从 MIT 协议，并且都尝试通过 MV* 模式来解决开发单页面应用的问题。它们都有类似的概念:视图，事件，数据模型和路由。我们先简单回顾一下有关的历史和背景知识，然后再展开深入比较这三款框架。
AngularJS 诞生于 2009 年，当时作为一个大型商业产品的一部分叫做 GetAngular。不久之后，Misko Hevery，GetAngular 项目创建者之一，花了仅仅三周时间，用 GetAngular 重写了一个曾经耗时 6 个月才完成的，有 17K 行代码的页面应用，并将代码削减到&1,000 行左右，于是成功的说服了谷歌开始赞助该项目，并将其开源，也就是我们今天看到&AngularJS 。Angular 的特点是拥有双向数据绑定，依赖注入，易于测试的编码风格，以及通过使用自定义指令可以简单的扩展 HTML。
&翻译的不错哦!
Backbone.js 是一个轻量级的 MVC 框架。诞生于 2010 年，它作为那种笨重全功能的 MVC 框架，比如说 ExtJS， 的一个代替品，迅速流行开来。 很多服务都使用了它，比如&Pinterest, Flixster, AirBNB 等等。
Ember 则要回溯到 2007 年，最开始是以 SproutCore MVC 框架展现在世人面前，由 SproutIt 开发，后来是 Apple，再后来到 2011 的时候，jQuery 和 Ruby on Rails 的核心贡献者 Yehuda Katz 参与了进来。有名的&Ember 用户包括了 Yahoo!, Groupon, 和 ZenDesk。
&翻译的不错哦!
社区是在选择一个框架的时候，要考虑的最重要因素之一。大社区意味着更多的答案，更多的第三方模块，更多的&YouTube 教程…你，明白了么。我做了个统计，截止 日，Angular 是绝对的王者，作为 GitHub 上第六大星级项目，在 StackOverflow 上的提问比 Ember 和 Backbone 加起来还多，你自己看:
Backbone.js
Github 的点赞星数
第三方模块
栈爆网的提问件数
YouTube 件数
GitHub 贡献者
Chrome 插件用户
所有这些指标，显示的仅仅是每个框架的当前状态。看看哪个框架增长最快也是很有趣的，你有福了，通过谷人希的趋势跟踪，你可以得到以下答案:
&翻译的不错哦!
4&框架大小
页面的加载时间是你网站成功的关键。当涉及浏览速度的时候，用户&— 所以很多情况下你要尽可能让你的应用跑得越快越好。使用框架，有两个因素会对应用的加载时间产生影响: 框架的大小和它启动的时间。
Javascript 资源通常都会被经过精简和压缩，所以我们来比较一下压缩版。但是只看框架的大小肯定不够的。Backbone.js，尽管是最小的&(只有 6.5kb)，但是必须 Underscore.js (5kb) 和 jQuery (32kb) 或者 Zepto (9.1kb)，而且你还有可能还有一些第三方插件要加进来。
& & 净大小
& & &包含依赖之后的大小
AngularJS 1.2.22
& & &39.5kb
& & &39.5kb
Backbone.js 1.1.2
& & &6.5kb
& & &43.5kb (jQuery + Underscore) & & &20.6kb (Zepto + Underscore)
Ember.js 1.6.1
& & 136.2kb (jQuery + Handlebars)
&翻译的不错哦!
Angular 和 Ember 都有模板引擎。而另一方面 Backbone，把这个选择权留给了你。感受模板引擎的异同最好的办法就是上点代码，好的，我们开始。我们将演示把一个列表转换成 HTML&列表的例子。
5.1 AngularJS
Angular 的模板引擎仅仅是在 HTML 上使用绑定表达式。而绑定表达式又仅仅是两层大括号而已:
&&&li&ng-repeat="framework&in&frameworks"&
&&&&&&title="{{framework.description}}"&
&&&&{{framework.name}}
5.2 Backbone.js
Backbone 可以和许多第三方模板引擎集成，默认的选择是&。 因为 Underscore 是 Backbone 的依赖项，你已经把它加载到页面中了，你无须添加任何额外的依赖关系就可以使用它的模板引擎。不爽的是，Underscore 的模板引擎非常初级，你通常不得不把 javascript 混进去，比如说:
&&&%&_.each(frameworks,&function(framework)&{&%&
&&&&&li&title="&%-&framework.description&%&"&
&&&&&&&%-&framework.name&%&
&&&%&});&%&
5.3 Ember.js
Ember 当前使用的是 Handlebars 模板引擎，的&Mustache 模板引擎的扩展。现在还有一个新的叫做 HTMLBars 的&Handlebars 变种可用。Handlebars 不关心 DOM – 它所做的仅仅是做一个简单的字符串变换。而 HTMLBars 则可以处理 DOM，所有的变量转换都有上下文感知。由于 HTMLBars 还没有流行，我们还是来看看用 Handlebars 方式打印列表方式:
&&{{#each&frameworks}}
&&&&&li&{{bind-attr&title=description}}&
&&&&&&{{name}}
&&{{/each}}
&翻译的不错哦!
6 AngularJS
Angular 为 Web 开发带来了许多创新的概念。双向数据绑定节省了大量的样板代码。比如下面的 jQuery 代码片段:
$('#greet-form&input.user-name').on('value',&function()&{
&&&&$('#greet-form&div.user-name').text('Hello&'&+&this.val()&+&'!');
由于 Angular 的双向绑定，你根本就不需要自己写代码。只需要在 HTML 模板里面声明绑定就可以了:
&input&ng-model="user.name"&type="text"&/&
Hello&{{user.name}}!
Promises 在 Angular 中扮演了一个重要的角色。Javascript 是单线程，基于事件循环的语言，这意味着许多操作(比如说网络通讯)都是以异步方式进行的。异步的 Javascript 代码会很快的就陷入了长长的嵌套回调，也就是臭名昭著的 “Pyramid Code” 或者叫做 “Callback Hell”。
相对比另外两个，Angular 不光有着更大的社区，更多的在线文档，而且还有谷歌在背后的推广和支持。所以，核心团队还在不断增长，产出更多的创新，以及改善开发生产效率的工具，比如: Protractor, Batarang, ngmin 和 Zone.js，一抓一大把。而且，开发团队还向用户征集需求。比如说，Angular 2.0 的所有设计文档你都可以从&&找到，任何人都可以直接给设计文档提建议。
&翻译的不错哦!
Angular 帮助你把构建应用的程序块划分为下面这几种类型：控制器(Controller)，指令(Directive)，工厂(Factory)，过滤器(Filter)，服务(Service)和视图(View) (就是模板)。它们被组织为模块形式，之后可以被另一个引用。每种类型有不同的作用。视图处理 UI，控制器处理 UI 背后的逻辑，服务用来处理和后台的通信，并且将共通的有关联的功能组件结合在一起，而指令通过定义新的元素，属性和行为，很容易的构造可重用的组件，以及HTML扩展。
自动脏值检查意味着，你不需要用 getter 和 setter 去访问数据模型 — 你可以修改任意范围(scope)的任意属性，然后 angular 会自动检测到变化，通知该属性的所有观察者(watcher)。
“Angular 的初衷是写出可测试的代码。” 中的这句话，包含了太多意思&– Angular 确实很注重分离，单元隔离，为 &和&&等基础内置服务提供了现成的，强大的 mock。
&翻译的不错哦!
Angular 常被人诟病的是指令那复杂的 API。 Transclusion，尤为突出，这个概念，把许多开发者搞得一头雾水，让你满脑子各种概念，比如编译函数(compiling function)，linking，函数的预处理/后处理(pre/post linking functions)，各种 scope 类型 (transclusion/isolate/child scope)，还有各种配置设置，需要相当的时间来掌握。
Angular 中的 scope 层次结构使用的是 Prototypal 继承，这又是一个为了迎合从面向对象语言，比如 Java 和 C#，过来的开发人员而提出的概念。不理解 scope 导致许多开发者开发很受伤&(比如说: ,
&翻译的不错哦!
&在视图层被广泛应用。表达式语言非常强大，有时候是强大过头了。这诱导开发者使用各种复杂的逻辑，甚至执行赋值运算和计算全部都放在模板中。把逻辑运算放在模板中让它非常难以测试，因为它变成不可能独立测试了。看看下面的例子，演示了如何滥用这种模板语言的:
&button&ng-click="(oldPassword&&&&checkComplexity(newPassword)&&&&oldPassword&!=&newPassword)&?&(changePassword(oldPassword,&newPassword)&&&&(oldPassword=(newPassword='')))&:&(errorMessage='Please&input&a&new&password&matching&the&following&requirements:&'&+&passwordRequirements)"&Click&me&/button&
许多情况下，指令名称的拼写错误，或者调用未定义 scope 方法，都会被忽略，并且很难被发现，特别是当你把复杂的指令 API 和上面提到的 scope 的继承弄到一起的时候。我见过有些苦逼花费一大堆时间抓耳挠腮想找出为什么 scope 中的一个绑定的事件没被回调函数触发，最后居然是因为用了驼峰(camelCase)命名，而没有用连字符分隔(hyphen-separated)拼写属性的名称(比如说).
&翻译的不错哦!
最后，是 Angular 的循环系统中, 要注意那“神奇的”脏值检查，它经常会给开发者惊喜。在非-Angular上下文运行的时候，很容易忘记调用&$digest() ()。也就是说，你必须非常小心，不要触发缓慢的观察者事件或者无限循环(例子: ,
还有 )。通常，对于一页上有大量的交互元素的页面，Angular会变得非常慢。有个很好的约定是，不要在同一页面上放超过 2,000 个活动的绑定。
&翻译的不错哦!
7 Backbone.js
Backbone 轻量，快速，内存占用小。学习曲线也是很平缓的，只需要几个简单的概念就能掌握&(模型/集合, 视图, 路由)。它有很棒的文档，代码简单，注释详细，并且这里还有一个源码，用来解释框架的工作细节。实际上你可以通读整个框架的源码，用不到一个小时去熟悉它。
因为又小又基础，你可以基于 Backbone 打造你自己的框架。一些基于 Backbone 的第三方框架的例子有&Aura, Backbone UI, Chaplin, Geppetto, Marionette, LayoutManager, Thorax, Vertebrae。用 Angular 和 Ember 你一般都要用框架作者给你的选择，有些可能会不适合你的工程需求和个人风格。Angular 2.0 承诺改变这种情况，通过构建更小的独立模块，使你可以选择和组合它们。不过我们还没看到它什么时候才能交付。
&翻译的不错哦!
Backbone 没有提供基本构造。它仅仅是提供了一些基础工具让你去创建，让你去决定如何构造应用，这有太多空要填了。比如说内存管理需要小心的处理。由于缺失视图生命周期管理，这会使得路由/状态的变化，很容易导致内存泄漏，除非你可以很清楚的处理一切。
诚然，Backbone本身不提供的功能，可以由第三方插件来填补，这也就意味着，在你创建应用的时候，有很多选择，因为一个功能通常有许多个备选插件。比如说，内嵌模型可以由下面这些插件提供:Backbone.DocumentModel, BackBone.NestedTypes, Backbone.Schema, Backbone-Nested, backbone-nestify, 这还是其中的一小部分。决定哪个更适合你的工程是需要调查的，这需要时间 — 而使用框架的一个主要目的是节省你的时间。
&翻译的不错哦!
Backbone 缺乏对双向数据绑定的支持，意思也就是说，你必须编写大量的样板来处理模型更新之后触发的视图更新。看看上面给出的例子，想想看&Angular.js 的双向数据绑定削减了多少样板代码。
Backbone 中的视图是直接操作 DOM 的，这让它们非常难做单元测试，也就更脆弱，更难以重用。常见的例子就是用 CSS 选择器查找 DOM 元素，改变CSS 类名，添加有同样类名的新元素或者把同样的 DOM 树包装到另一个元素，都会打乱你的 CSS 选择器以及应用的渲染。
&翻译的不错哦!
8 Ember.js
Ember.js 主张约定优于配置。也就是说，无需编写大量的样板代码，Ember 会自动推导出许多配置本身，比如在定义一个路由资源的时候，可以自动判定路由的名称和控制器。Ember 甚至会在你没定义控制器的时候，自动为你的资源生成一个。
Ember 包含了一个优秀的路由和一个可选的数据层，叫做 ember data。和其他两个框架不同，它们的数据层非常小(Backbone 的集合/模型和 Angular 的 $resource)，Ember 有一个拿来即用的非常成熟的数据模块，只需要简单的配置，就可以和后台的&Ruby-on-Rails 或者其它的 RESTful JSON API 集成得非常好。它还可以来支持面向 mock API 开发以及测试。
&翻译的不错哦!
性能是 Ember.js 设计的主要目标。诸如&&这个概念，可以确保数据的变化只导致单个 DOM 更新，即使同一块数据进行了多次更新也是一样，还有, 还有可以在编译时或在服务端对 HandleBars 模板进行预编译的能力，都可以帮助你保证应用的负载，保证它跑得足够快。
Ember 的 API 在它稳定版出来之前变化太大了。这导致了有大量的过期内容和不能再运行的例子，这会新进开发者开始使用这个框架时感到非常困惑。看看&，你就会知道我说的是什么意思了。这里有太多的大变更了，这就让许多栈爆网的回答和编码例子变得毫无意义了(比如说。
&翻译的不错哦!
Handlebars 为了和数据模型一致，用了太多的&&script& 标签来污染 DOM 了。这会在迁移到&HTMLBars 的时候变得毫无意义，但到那时，你的 DOM 树上全都是 &script& 标签，会哪些是你的代码了。还有最糟糕的部分 – ，或者影响和其他框架的集成，比如说&。
我们已经看过三个框架的长处短处。Ember 的综合能力，其中的 MVC 结构，对于那些曾经在&Ruby, Python, Java, C# 或者其他面向对象语言中有过&MVC 编程背景知识的程序员来说非常有意义。Ember 还带来了媲美桌面应用的性能，而且还因为约定优于配置的原因，可以让你节省非常多样板代码。
&翻译的不错哦!
Backbone 崇尚极简主义。它够小，够快，够简单，但是提供了你构建应用所需要的最小集(许多情况下，甚至要小于最小集)。
Angular 的扩展 HTML 的创新方法，对于骨子里是 web 开发者的人来说非常有意义。它有强大的社区，有谷歌在后面支持它，它不断沉淀和成长。它不但适用于快速原型开发，还适用于大型生产应用。
&翻译的不错哦!
ember-data还是个玩具