6 AngularJS6.1 好处Angular 为 Web 开发带来了许多创新的概念。双向数据绑定节省了大量的样板代码。比如下面的 jQuery 代码片段:
由于 Angular 的双向绑定，你根本就不需要自己写代码。只需要在 HTML 模板里面声明绑定就可以了:
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 确实很注重分离，单元隔离，为 $http 和 $timeout 等基础内置服务提供了现成的，强大的 mock。 6.2 痛处Angular 常被人诟病的是指令那复杂的 API。 Transclusion，尤为突出，这个概念，把许多开发者搞得一头雾水，让你满脑子各种概念，比如编译函数(compiling function)，linking，函数的预处理/后处理(pre/post linking functions)，各种 scope 类型 (transclusion/isolate/child scope)，还有各种配置设置，需要相当的时间来掌握。 Angular 中的 scope 层次结构使用的是 Prototypal 继承，这又是一个为了迎合从面向对象语言，比如 Java 和 C#，过来的开发人员而提出的概念。不理解 scope 导致许多开发者开发很受伤 (比如说: 这, 这 还有这)。 Angular 表达式 在视图层被广泛应用。表达式语言非常强大，有时候是强大过头了。这诱导开发者使用各种复杂的逻辑，甚至执行赋值运算和计算全部都放在模板中。把逻辑运算放在模板中让它非常难以测试，因为它变成不可能独立测试了。看看下面的例子，演示了如何滥用这种模板语言的:
许多情况下，指令名称的拼写错误，或者调用未定义 scope 方法，都会被忽略，并且很难被发现，特别是当你把复杂的指令 API 和上面提到的 scope 的继承弄到一起的时候。我见过有些苦逼花费一大堆时间抓耳挠腮想找出为什么 scope 中的一个绑定的事件没被回调函数触发，最后居然是因为用了驼峰(camelCase)命名，而没有用连字符分隔(hyphen-separated)拼写属性的名称(比如说这). 最后，是 Angular 的循环系统中, 要注意那“神奇的”脏值检查，它经常会给开发者惊喜。在非-Angular上下文运行的时候，很容易忘记调用 $digest() (例子)。也就是说，你必须非常小心，不要触发缓慢的观察者事件或者无限循环(例子: 这,这 还有 这)。通常，对于一页上有大量的交互元素的页面，Angular会变得非常慢。有个很好的界定是，不要在同一页面上放超过 2,000 个活动的绑定。 7 Backbone.js7.1 好处Backbone 轻量，快速，内存占用小。学习曲线也是很平缓的，只需要几个简单的概念就能掌握 (模型/集合, 视图, 路由)。它有很棒的文档，代码简单，注释详细，并且这里还有一个注释版源码，用来解释框架的工作细节。实际上你可以通读整个框架的源码，用不到一个小时去熟悉它。 因为又小又基础，你可以基于 Backbone 打造你自己的框架。一些基于 Backbone 的第三方框架的例子有 Aura, Backbone UI, Chaplin, Geppetto, Marionette, LayoutManager, Thorax, Vertebrae。用 Angular 和 Ember 你一般都要用框架作者给你的选择，有些可能会不适合你的工程需求和个人风格。Angular 2.0 承诺改变这种情况，通过构建更小的独立模块，使你可以选择和组合它们。不过我们还没看到它什么时候才能交付。 7.2 痛处Backbone 没有提供基本构造。它仅仅是提供了一些基础工具让你去创建，让你去决定如何构造应用，这有太多空要填了。比如说内存管理需要小心的处理。由于缺失视图生命周期管理，这会使得路由/状态的变化，很容易导致内存泄漏，除非你可以很清楚的处理一切。 诚然，Backbone本身不提供的功能，可以由第三方插件来填补，这也就意味着，在你创建应用的时候，有很多选择，因为一个功能通常有许多个备选插件。比如说，内嵌模型可以由下面这些插件提供:Backbone.DocumentModel, BackBone.NestedTypes, Backbone.Schema, Backbone-Nested, backbone-nestify, 这还是其中的一小部分。决定哪个更适合你的工程是需要调查的，这需要时间 — 而使用框架的一个主要目的是节省你的时间。 Backbone 缺乏对双向数据绑定的支持，意思也就是说，你必须编写大量的样板来处理模型更新之后触发的视图更新。看看上面给出的例子，想想看 Angular.js 的双向数据绑定削减了多少样板代码。 Backbone 中的视图是直接操作 DOM 的，这让它们非常难做单元测试，也就更脆弱，更难以重用。常见的例子就是用 CSS 选择器查找 DOM 元素，改变CSS 类名，添加有同样类名的新元素或者把同样的 DOM 树包装到另一个元素，都会打乱你的 CSS 选择器以及应用的渲染。 8 Ember.js8.1 好处Ember.js 主张约定优于配置。也就是说，无需编写大量的样板代码，Ember 会自动推导出许多配置本身，比如在定义一个路由资源的时候，可以自动判定路由的名称和控制器。Ember 甚至会在你没定义控制器的时候，自动为你的资源生成一个。 Ember 包含了一个优秀的路由和一个可选的数据层，叫做 ember data。和其他两个框架不同，它们的数据层非常小(Backbone 的集合/模型和 Angular 的 $resource)，Ember 有一个拿来即用的非常成熟的数据模块，只需要简单的配置，就可以和后台的 Ruby-on-Rails 或者其它的 RESTful JSON API 集成得非常好。它还可以通过设置 fixtures来支持面向 mock API 开发以及测试。 性能是 Ember.js 设计的主要目标。诸如 The Run Loop 这个概念，可以确保数据的变化只导致单个 DOM 更新，即使同一块数据进行了多次更新也是一样，还有计算属性的缓存, 还有可以在编译时或在服务端对 HandleBars 模板进行预编译的能力，都可以帮助你保证应用的负载，保证它跑得足够快。 8.2 痛处Ember 的 API 在它稳定版出来之前变化太大了。这导致了有大量的过期内容和不能再运行的例子，这会新进开发者开始使用这个框架时感到非常困惑。看看 Ember Data 变更日志，你就会知道我说的是什么意思了。这里有太多的大变更了，这就让许多栈爆网的回答和编码例子变得毫无意义了(比如说这)。 Handlebars 为了保持模板和数据模型一致，用了太多的 <script> 标签来污染 DOM 了。这会在迁移到 HTMLBars 的时候变得毫无意义，但到那时，你的 DOM 树上全都是 <script> 标签，会几乎无法辨认哪些是你的代码了。还有最糟糕的部分 – 这会打乱你的CSS样式，或者影响和其他框架的集成，比如说 jQuery UI 的排序。 9 总结我们已经看过三个框架的长处短处。Ember 的综合能力，其中的 MVC 结构，对于那些曾经在 Ruby, Python, Java, C# 或者其他面向对象语言中有过 MVC 编程背景知识的程序员来说非常有意义。Ember 还带来了媲美桌面应用的性能，而且还因为约定优于配置的原因，可以让你节省非常多样板代码。 Backbone 崇尚极简主义。它够小，够快，够简单，但是提供了你构建应用所需要的最小集(许多情况下，甚至要小于最小集)。 Angular 的扩展 HTML 的创新方法，对于骨子里是 web 开发者的人来说非常有意义。它有强大的社区，有谷歌在后面支持它，它不断沉淀和成长。它不但适用于快速原型开发，还适用于大型生产应用。 |
