BT

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

作者 胡键 发布于 2009年1月18日 |

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

最近,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专题

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

默认选最熟悉的框架 by 任 逍遥

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

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

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

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

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

Re: 默认选最熟悉的框架 by 胡 键

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

jquery根本不算是框架 by zhang bo

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

应推出新的Html版本 by Great Way

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

Re: jquery根本不算是框架 by 曹 云飞

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

Ajax谈不上用什么框架 by Pan Liwei

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

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

8 讨论

深度内容

提供反馈
错误报告
商务合作
内容合作
InfoQ.com及所有内容,版权所有 © 2006-2014 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP合作伙伴。
隐私政策
BT