JavaScript富应用MVC MVVM框架

对框架的挑选 Ember.js、Backbone.js、Knockout.js、Spine.js、Batman.js ， Angular.js

1. 轻量级的应用选择哪一个会比较好？
2. 那一个比较简单，容易上手
3. 哪一个开发周期最短？

具体可以看   (英) Rich JavaScript Applications – the Seven Frameworks

Web前端开发：为何选择MVVM而非MVC

由于工作关系~一直没时间细细研究下这些框架的源码~ 早期就看过Backbone.js与EXT4的MVC

最近开始研究业界小有名气司徒正美的mvvm框架avalon

为什么放着Angular，Ember不去分析,而去研究avalon呢, 看了http://rubylouvre.github.io/mvvm/

其实作者就是基于Angular，Ember，knockout这种成熟的框架中，演化出来的avalon，所以avalon我不说媲美这些框架，但是从研究的角度入手，我觉得未必不可

核心的功能avalon都能够完成，只是组件不够多，毕竟是个人行为的 ,  avalon 源码分析目录 , 博主已经开始研究angular,尽量同步推出源码分析

对比：

1. angular是找大而面的道路，因此体积非常庞大，1.6-1.7万行；
2. avalon旨在提供一种远离DOM操作的前端开发体验，0.6.3只有2420行，min只有29kb。
3. avalon从angular抄来了不少好东西，如{{}}插值表达式，ms-model（通过事件实现双向同步），ms-controller（为了VierModel指定作用域范围），但都做了增强，{{aaa|html}添加html过滤器就能输出innerHTML，ms-model可以通过data-observe来开关双向同步，ms-controller拥有孪生兄弟ms-important。
4. avalon的$watch与ms-bind方法提供比angular强大得多回调功能。
5. avalon拥有像knockout, emberjs那样的计算属性， angular没有。
6. avalon与angular都拥有监控数组，但avalon的监控数组像knockout那样拥有大量好用的方法，能自动同步页面，angular的则相当弱。
7. avalon与angular都拥有定义UI的功能（将一个元素变成一个UI组件），angular是使用自定义标签，avalon是使用ms-ui属性，但自定义标签在旧式IE并不好使，并且可能随着浏览器的升级，浏览器会添加一个与你一模一样的新标签。avalon则安全多了，并且拥有12UI组件可做参考，实现起来非常简单。
8. avalon是采取边扫描边转换绑定的策略，用户打开页面后立即能看到效果，angular是要全部扫描后才转换绑定，因此用户可能看到一些奇异的模板。
9. avalon是通过define方法来定义ViewModel，并有scan方法指定作用的元素与ViewModel。angular要求用户将xxxxCtrl函数暴露到全局作用域下，框架自己去取去组装。
10. avalon在ViewModel有个$json，就是ViewModel对应的纯数据的Model（ViewModel每次被操作，都会自动同步View与Model的），我们可以直接将它放到AJAX中使用。angular没有独立的Model,需要自己转换。
11. avalon是使用Object.defineProperty与VBS实现ViewModel，angular则是将整个xxxxCtrl函数进行编译，转换一大堆getter, setter从而实现双向绑定，因此angular的体积是相当庞大的。
12. avalon的绑定值可是ViewModel的属性或数组或表达式， angular则允许用户在视图定义新变量，新对象，这是个不好的特征，会让页面非常难维护。
13. avalon的绑定已经强大到让用户完全脱离DOM写业务，顶多是取一下表单元素的checked, disabled等状态值，angular还是传统的思路，只是在1.0后添加数据绑定机制。

其实说了一堆，并非是说angular不够好avalon超过angular，正如作者所说angular是找大而面的道路，因此体积非常庞大，就跟EXT一样想什么都想揽着.

各个框架的技术速览

Backbone

• 作者：Jeremy Ashkenas and DocumentCloud
• 内容：
  • Model-View模式，MIT 许可
  • 最小的类库——仅仅一个文件，800行代码！
  • 很专一的功能——仅仅提供REST持久化模型以及简单的路由和回调，这样就可以让你知道什么时候去渲染实体（需要自己设置渲染机制）
  • 最著名的，被许多大牌网站使用（或许是因为它小而易于被接受）
• 优点：
  • 它很小，你可以在使用之前通过读源代码来弄懂它。
  • 对你的服务端架构和文件结构都没有影响，可以只在页面的一小部分起作用，并不需要考虑整个页面。
  • Jeremy就像一个禅宗大师，对所有的问题都很有观点。他就像一个大人指导着一群吵闹的孩子。
• 项目地址：GitHub ，官网
• 发布时间：两年前

Meteor

• 作者：Meteor开发团队，他们刚刚获得了1120万美元的融资所以可以全职开发Meteor
• 内容：
  • 这是一个来自未来世界的令人惊讶的框架，它拥有你所没有见过的东西（可能除了Derby)
  • 在服务端（Node.js + Mongo）和客户端使用相同的代码，使二者(包括数据库）连通起来.通过WebSockets来同步服务端和所有的客户端。
  • 当修改代码时就可以“实时部署”——客户端会快速更新而不会丢失他们的内容。
  • 如果提供视频观看会更加合适【演示】
  • 和其他的人一样，我真心希望这个项目会成功——WEB开发需要一些像这样有激情的项目来向前推进。
• 优点：当你收购了web开发的一些陈规旧俗，Meteor可以让你走在前沿。
• 项目地址： GitHub,官网
• 发布时间：仍是早期版本，目前我不知道有哪些网站正式使用Meteor。但是它的核心团队正在认真地做着这个项目。

Ember

• 作者: Yehuda Katz (Rails和Jquery的先前开发者),Ember团队已经 Yehuda 的伙伴Tilede
• 内容:
  • 它包含建立一个"强大的Web应用"的一切,采用的是MIT许可
  • 在所有的框架中是功能最强大,当然库的大小也很大.
  • 它的着眼点在于怎样把怎样把一个页面分解成一个个有层次的控件,然后通过一个有状态的路由系统来连接起来.
  • 正在开发更加精细的数据接入类库(Ember.Data)
  • 会在运行时对所有的页面控制,因此对于使用了很多内容的部分(如silverlight,ajax,flash)可能不合适.
  • 文件结构和URL都是固定的,但是可以被重写.
  • 其设计灵感来自Rails和Cocoa
  • 使用:它为Rails提供工程模版(你也可以通过手动配置来使它应用在别的服务端技术上)
• 优点:常见的问题应该有常见的解决方法--Ember提供了所有的常见解决方案,你只需要考虑对你的应用程序来说那个是适用的.
• 项目地址GitHub,官网;
• 开始时间: 仍然不是1.0的发布版本,不过很快会发布,API到时候也会发布(**译者注:已经发布1.0的pre版本)

AngularJS

• 作者:google的开发者,主要是他们内部使用,并且采用MIT协议
• 内容:
  • MVW(Model-View-Whatever )模式
  • 基于DOM的模版声明式绑定.
  • 内置基础的url路由和数据序列号
  • 工具:他们实现了一个可以让你在调试时监视你的数据模型的chrome的调试插件,以及一个针对Jasmine 测试框架的插件
• 优点:
  • 按照他们所宣传的，这是一个未来浏览器会原生支持的框架，所以我们应该现在就用这种方式来编程。
  • 对服务器端的架构和文件结构没有影响，可以用在不需要对整个页面控制的小部分。
• 项目地址： GitHub,官网
• 开始时间：已发布（曾在google使用过）

Knockout

• 作者： Knockout团队和社区（包括我在内目前核心团队有三个成员）
• 内容：
  • Model-View-ViewModel (MVVM) in JavaScript, MIT licensed
  • 关注与富UI：基于DOM的声明式绑定，拥有自动依赖检测的"观察者“模型
  • 不强制绑定URL路由和数据——和其他第三方库结合（例如使用Sammy.js做路由，采用ajax方式存储数据）。
  • 着重关注于易用性，有大量的文档和交互的例子
• 特点：
  • 专注于UI,支持IE6
  • 对服务器架构和文件系统没有影响。可以用在不需要对整个页面控制的小部分。
• 项目地址： GitHub,官网
• 开始时间： 发布将近两年

Spine

• 作者： Alex MacCaw
• 内容：
  • MVC in JavaScript, MIT license
  • 最初作为O’Reilly一本书的示例代码，最终演变为一个开源代码工程
  • 是Backbone的一个克隆版本（就像名字那样）（译者注：Spine和Backbone都有脊柱的意思)
• 特点：你希望用不同的方式来使用Backbone二者不同可以参看这里
• 项目地址： GitHub,官网
• 开始时间： 已经发布1.0.0版本

Batman

• 作者：Shopify团队（一个电子商务平台公司）
• 内容：
  • 支持Javascript的MVC架构，几乎是为Rails+CoffeeScript开发者设计的。MIT 许可
  • 定制性最强的一个框架，你必须按照它的约定（例如文件结构和URL路径），否则，就像它”高傲“的作者们所说的：“不遵循约定就别用”。 *全栈式的框架，拥有丰富的模型，视图和控制器及路由。当然也有观察模式的机理。 *基于DOM的模版
• 特点： 如果你使用Rails和CoffeeScript，你会得心应手……
• 项目地址： GitHub,官网
• 开始时间：目前是0.9版，预计在未来几个月内发布1.0版本。

CanJS

• 作者：bitovi团队（一个js咨询培训公司）
• 内容：
  • MVC in JavaScript, MIT licensed
  • REST-persistable模型，基础的路由，基于字符串的模版。
  • 并不很出名（我在上周前还不知道它），尽管它是一个很老的javascript mvc项目的重新开放。
• 特点：致力于构建一个轻量的，提供上述所有框架都具有功能特性的最好的框架。
• 项目地址： GitHub,官网

总结

如果你在考虑究竟那个是最适合你的项目，我觉得应该考虑两个方面：

• 应用范围： 你希望一个框架或者类库能够帮助你做多少东西？你是希望有一个可以让你从0开始全程都为你提供架构帮助的全能框架，还是希望自己定制模式和类库？不管选择那种，对不同的项目和团队都是有价值的。

• 设计美学：你是否看过这些框架并且想自己构建一个小型的类库？你喜欢这样做吗？不要根据局限与描述或者功能列表去选择。忽略你自己的编码习惯就像仅仅根据小说的目录去买书或者是根据个人简历和履历来选择配偶。

除了不同的地方，我可以肯定上述这些技术都遵循的一个功能：模型和视图分离。这是一种在20年钱就已经存在的经典设计模式。即使你在构建最简单的web应用界面你也能从这种模式中受益。