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

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

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