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应用界面你也能从这种模式中受益。