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的过程，你还有什么要补充的？