如何选择最合适的Ajax框架？

作者 胡键 发布于 2009年1月18日 下午9时4分

社区

Architecture,

Java

主题

RIA,

JavaScript,

动态语言

标签

GWT,

Dojo,

ExtJS

与早些年相比，如今开发者面临的选择可谓是极其丰富。各类框架层出不穷、百花齐放。在选择不断丰富的同时，随之而来的烦恼则是“该挑哪个？”。从某种意义上来说，有时“挑得眼都乱了”比起“无框架可选”还要“折磨”人。

最近，Appfuse的缔造者Matt Raible在其博客发表了他们选择Ajax框架的过程，并向社区征求意见。在文章的开始Matt说明了他们的决策过程：

1. 确定准备用来搭建原型的框架简表。
2. 用每个框架创建一个应用原型。
3. 记录调查情况，并创建一个包含重要标准的矩阵。
4. 为记录文档创建概括性的幻灯片。
5. 交付文档、幻灯片（含示例）和推荐。

随后Matt对每一步进行了详细描述，并给出了他们的文档模板和选择标准列表。其中文档模板是：

介绍
	
 Ajax框架候选
 （介绍和说明选择原因）
 
 项目信息
 （历史）
 （许可证/花费）
 （提交者人数）
 （支持情况）
 （邮件列表的流量（11月/12月 2008））

矩阵和注释

结论

文档中引用的矩阵如下（其中Dojo、YUI、GWT和Ext JS是Matt这次选择的候选）：

权重	标准	Dojo	YUI	GWT	Ext JS	注释
#	对客户来说重要的标准	0..1	0..1	0..1	0..1	关于评定的注释说明

Matt说明了他们填表的策略：

• 客户调整每个标准的权重（必要时移除/增加），所有权重合计为1。
• 我们将每个框架分成0、0.5或1，其中0 = 不满足标准，0.5 = 部分满足，1 = 满足。

Matt在文末列出了客户向他们提供的标准列表：

• 文档/教程/帮助的质量
• 对浏览器的支持情况（最重要的浏览器/版本，以Web统计为准）
• 可测试性（尤其是Selenium的兼容性）
• 许可证
• 项目健康/采用情况
• 性能
• 伸缩性
• 灵活性/可扩展性
• 生产力（应用开发，Web开发）
• 部件/组件库的丰富程度
• 图表功能
• 创建新部件的能力
• 与现有Java团队技能的匹配情况
• 易部署性（针对操作人员、QA和用户而言）
• 一般的风险程度
• 与现有站点（它包含了Prototype）集成的能力
• 使用CSS来进行风格定义的简单程度
• 验证（尤其是标记表单元素无效）
• 组件的主题/装饰
• CDN的可用性（即Google的Ajax库API或Ext CDN）

遗憾的是，对于Matt的帖子，回复虽然不少，但人们的兴趣明显不在于这个选择过程。人们似乎对Matt的选择结果和他们决定的候选名单更感冒，并有不少人纷纷建议这4种选择之外的其他选择，其中以JQuery居多。

单就选择Ajax框架来说，这篇帖子罗列了类似的考虑：

• 服务器独立或相关？
• 是否有结构化JavaScript的增强机制？
• 你书写组件的重用性？
• 框架当前的文档化程度？
• 是否有你需要的特性？
• 项目持续的时间有多长？
• 项目的支持类型是什么？社区或商业？
• 框架的学习曲线有多陡峭？
• 谁将访问你的站点？

虽然Matt帖子反映了Ajax框架的选择过程，但是就其过程来说对于其他框架的选择也不乏参考价值。根据实际情况更换候选列表和选择标准，很快就可以将这个过程复制到其他类型的框架上。InfoQ中文站的读者，请问你是否有这样一个类似的过程来确定框架？如果有，它是一个什么样的过程？对于Matt的过程，你还有什么要补充的？

阅读更多Ajax内容，请浏览：InfoQ中文站Ajax专题。

1. 返回顶部

   默认选最熟悉的框架

   2009年1月19日 上午1时38分 发表人 逍遥 任

   没有框架是为你准备的，总要手工一些功能,只要框架的代码入侵别太严重就OK

   回复

2. 返回顶部

   决策的候选框架居然没有jQuery，这个决策结果可能从根本上失败了

   2009年1月19日 上午4时5分 发表人 cao yunfei

   过程第一步，# 确定准备用来搭建原型的框架简表。这一步需要投入更多资源来做，否则后面的步骤可能差之毫厘，谬之万里了。

   回复

3. 返回顶部

   Re: 决策的候选框架居然没有jQuery，这个决策结果可能从根本上失败了

   2009年1月19日 下午8时40分 发表人 gem fox

   关于这一点，回复中亦有质疑。matt的回答是他们也考虑过，但是他们的重点是更关注于界面。而相比起其他来说，其他几个的ui库更全一些。这种考虑倒是和“是否有你需要的特性？”这一标准能够对应上。

   回复

4. 返回顶部

   Re: 默认选最熟悉的框架

   2009年1月19日 下午8时44分 发表人 gem fox

   总会有面临选择的时候，而且最熟悉的未必就是最适合的。这种情况下，一个决策过程当然必要。试想在多年前，有几个人会认为代码侵入性太强是个问题？和其他行业一样，软件也是个不断成熟和发展的过程。而人的需求也是不断提高的过程。

   回复

5. 返回顶部

   jquery根本不算是框架

   2009年1月19日 下午11时0分 发表人 bo zhang

   Jquery当然不能列入候选，因为这里说的是框架，而Jquery只是函数库罢了，而不能称之为框架。作为js框架，尤其是面向企业应用，必须具备框架特征，比如嵌套式的复用和扩展机制等等，而这些在jquery是看不到的。

   回复

6. 返回顶部

   应推出新的Html版本

   2009年1月20日 上午2时54分 发表人 Way Great

   为什么不推出新的Html版本，支持更丰富的控件，支持数据绑定，让客户端界面渲染的工作交给浏览器作，javascript只负责和服务器端的数据交互

   回复

7. 返回顶部

   Re: jquery根本不算是框架

   2009年1月20日 下午6时50分 发表人 cao yunfei

   jQuery有plugin支持扩展，有extend算子支持继承，您的“嵌套式的复用”指的是什么，除了继承还需要什么功能来支持“嵌套式的复用”？

   回复

8. 返回顶部

   Ajax谈不上用什么框架

   2009年3月8日 下午8时51分 发表人 Liwei Pan

   Ajax给我们带来的是Web应用的服务器端开发的逻辑层和视图层的测地分离，中间的接口便是Web服务和JSON数据模型。所以，我觉得jQuery就足够了，选择她的理由是用她写出来的代码非常的优雅，可读性强，极力推荐！

   回复

• 更早的 >