BT

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

作者 胡键 发布于 2009年1月19日 | 被首富的“一个亿”刷屏?不如定个小目标,先把握住QCon上海的优惠吧!

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

最近,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 讨论
提供反馈
错误报告
商务合作
内容合作
Marketing
InfoQ.com及所有内容,版权所有 © 2006-2016 C4Media Inc. InfoQ.com 服务器由 Contegix提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司 京ICP备09022563号-7 隐私政策
BT

We notice you’re using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.