——摘自《HTML5移动Web开发实战》 c12 12.2
1、技术成熟度
一项技术是否成熟，决定了你的应用是否稳定。特别是新的技术通常意味着缺乏稳定性，在需要保证正确性和稳定性的场景（比如面向金融或者面向数量巨大的最终用户的应用），选择新技术时一定要慎重再慎重，对于一些不关键的容错性高的场景（比如内部系统），选择新技术的风险就会小很多。
2、文档
由于程序员基本都是由人类构成，因此文档好坏基本上制约着程序员的工作效率。无论你看到某项技术吹的再天花乱坠，请一定记得看看它的文档是否健全优雅，示例是否清晰易懂，否则你发现有坑时，说不定你已经踩进去了。
3、适用场景
不同种类的技术工具一定有它适用的针对性场景，即便是号称“大一统”和“全能”的框架技术，也有它所不适用的地方，比如YUI功能齐全，但在短平快的广告宣传页使用它就显得杀鸡用牛刀了，同理，目标相似的技术也会有不同的地方，在这方面必须要结合你自己的应用具体情况来分析，比如sugar.js和underscore.js都是用于对原生JavaScript对象提供实用函数，sugar就能提供更加“直觉式”的编程体验，而underscore则对于混合编程环境提供了sugar无法提供的冲突处理。
4、应用规模
如果你的应用代码规模很大，你不得不考虑组织代码的方式，是选择模块化（CMD/AMD）还是用继承树（closure library）？打包工具、压缩工具和校验工具这些东西随着应用规模的上升都不得不逐渐提上你的日程，一项技术是否满足打包压缩模块化等需求，也是你需要考虑的地方。
5、学习曲线
学习曲线通常是工程师或者工程师头儿在技术选型时经常忽略的地方。比如在你自己非常了解一项技术A时，经常会选择它或者与它相关的技术，而忽略和你合作的人对A的认知情况。由于学习一项技术总是需要时间，因此对于整个团队而言，学习曲线陡峭的技术很可能成为开发效率的杀手，而作为技术选型者自己却很难意识到。但另一方面，学习曲线陡峭的技术通常来是较革新的，并且长期来看是高效率的，因此如果你的应用是一个长期不断维护的项目，尝试较革新的能反映技术趋势的工具也未尝不可。
6、社区力量
如果你是开源运动的忠实拥护者（或者说你是没有那么多钱寻求技术支持的穷人），那么一项技术的社区力量是否强大很大程度上影响了你踩了坑是否有人帮你。jQuery之所以如此流行，也离不开社区的力量，无数人在为jQuery贡献教程、跑测试和报bug，在论坛里或问答网站里解答具体的问题……如果你不幸选择了一项没有社区支持甚至作者本人都不响应的开源技术，那么遇到问题的时候你就可以去买点手帕抹泪吧。
同样的，如果你自己在开发或维护某个开源项目，那么除了写代码，培育其社区也是极其重要的工作。
7、技术缺点
所有的技术都有缺点，做决定前，一是要认清这项技术的缺点，二是要考虑你是否能接受它的缺点。
8、团队水平
这个说起来让人难堪，但你不得不承认任何团队中的人员水平都是有高有低的，一个团队的平均水平也是有高有低的。如果一项技术过于简单，二团队水平又非常高，很可能出现重造轮子甚至辱骂原作者这样的事儿，而相反在选用技术过于复杂，团队水平不高的情况，则非常容易出现误用乱用最后甚至导致代码不可维护的情况出现。
9、兼容性
对于前端开发人员来讲，兼容性尤为重要。几乎所有前端技术都会提供一个兼容性列表，认真研读它，并和你自己应用需要兼容的浏览器和设备做好仔细调研对比，这是一个门当户对的问题，光有爱情是不够的。
10、迭代周期
通常来讲，不同公司的产品迭代速度是有很大差别的，这种节奏对技术选型也有很大影响。比如在迭代周期慢的传统软件公司，如果选用更新频繁的技术，那么很可能上一个版本的应用中出现的bug在下一次更新前都无法解决，而对于迭代周期比较快的互联网公司影响则没那么大。迭代周期快的产品对较新的更新频繁的技术容忍度会高很多。