1. 引言
从以下几个方面来阐述这个问题：
特性。
稳定性。
性能。
包生态。
社区。
学习曲线。
文档。
工具。
发展历史。
团队。
兼容性。
趋势。
2.概述 & 精读
特性
当你调研一个 JS 库，功能当然是最重要的，就好比 React 的用于开发 UI 界面非常方便，这是流行起来的一部分因素。
但同时 React 解决的问题很聚焦，于是把例如 Router 和 Store 部分交给社区给解决方案，这就让 Vue 的官方维护生态模式发展了起来。但这更多取决于你的偏好，像 lodash 这种精简的库也会长盛不衰，重要的是这个库提供的能力是否解决了你的业务问题。
评分：A - BUG 很少，方便调试。B - 不会影响你的稳定性，比如出 BUG 概率和你的业务代码相近。C - 引入该库会让你背线上故障。
性能
如果让用户 15 秒才能打开网页，那一切都是徒劳。
拿 PReact 为例子，为什么 API 相同的轮子可以活下来？因为体积小，而且 PReact 把宣传重点放在性能上。
如何一句话说明白你不是在造无用的轮子？性能更好。
包生态
用过 monaco-editor 吗？大家都在用 webpack 但它却走 amd 路线，我不知道你用什么方法让它支持 commonjs 的，但这一定耽误了你不少时间。
包生态包括第三方包的成熟度，包的使用难易度，支持多少种模块化方案，是否支持 TS，有没有管理好自己的依赖等等。
开箱即用是最好的，有长期维护组织的更佳。
同时不要有太多相互竞争的社区方案为佳。比如工具库用 lodash 这很容易，但 React 数据流方案选择哪个？太多的竞争对手不断写软文抢夺用户（程序员）的注意力，试图说服他们加班重构。
社区
能否快速在 Stack Overflow 搜到问题的答案能反映出社区的活跃度，不论是官方文档还是第三方进行的问答。
社区越活跃，帮你提前踩的坑就越多，如果你遇到一个大家都没有遇到过的问题，并不代表你用得有多深度，而可能你根本就用错库了。
不要以为把库功能做的强大，就算难用点也会有用户跪舔，这是幻觉。
Vue 之所以那么火爆，是因为原生 HTML 的门槛比 JSX 低，而使用 React 的用户往往都觉得 JSX 比 HTML 门槛低。我也不知道该怎么描述，从 JS 可以产生一切的角度，学习 HTML 反而被认为是高门槛的体现。
所以认清现实，JSX Star 多并不是其理论有多先进（理论确实先进），而是很多人觉得整体学习维护成本比 HTML 低。
文档
写文档的人一般都是库的作者，这种人一般经验会比较丰富，写起文档一般不会考虑初学者的感受，所以找到一份对初学者友好的文档还是挺不容易的。
对于库的维护者，要站在初学者角度去写文档，站在使用者角度，如果文档开头就看不懂的话，最好尽早换个文档或者换个库。
工具
工具可以从多个维度体现出这个库的优势，首先是确实带来了使用方便，其次展示了团队维护实力的雄厚（精力溢出到可以做周边工具了）。
Redux 之所以这么火，Redux dev tools 功不可没，笔者读过一些心理学书籍，也经历过一些技术选型，看到 Redux dev tools 的图形化界面后，大脑因为受到视觉冲击比理性的逻辑思考大太多，潜意识里给 Redux 加了不少分，导致讨论结果都变得不太理性了。
如果你的库能图形化表达，或者做一个 PPT 或者辅助工具，那一定会大大加分。（React chrome 插件在打开 react 做的网页时亮起来真的很酷，这个勋章很有仪式感，以至于我不想换一个框架）
发展历史
一个 Star 10K 的库，如果最早提交是十天前，就算不是刷的也最好也不要用，因为不知道哪天作者就不再维护了。
历史越悠久的库使用风险越小，除非它所在的面被淘汰（技术栈、生态、编程语言等等）。
团队
看谁是这个库背后的男人。大公司广泛使用的开源库，并且有一定国际影响力，而且大厂也有成功开源历史经验的话，就会增加说服力。
但 Vue 就是个例外，几乎凭尤大一人之力打造，对这种情况，笔者想说的是，一个真心热爱技术并践行全职维护的人，也许比一个背着 KPI 的团队维护副产品更靠谱。
兼容性
除了浏览器兼容性，库 API 的兼容性也非常重要。当你很容易联系到作者，并且改动 API 的建议被很快采纳时，你就要小心了。
React Router 3 -> 4 升级带来的阵痛大家都有体会过，babel7 放弃 stage 0-4 也带来不少吐槽，Angular1 和 Angular2 的区分直接让很多人粉转黑了。虽然许多时候频繁的更新是为了增添新功能，但如果带来 API 兼容问题，反而会招来反感。
假如你们团队维护的 10 年间，因为某个库作者非常勤奋的更新导致以时间为维度，均匀分布了数十种不同的版本，你会发誓下一个项目不再使用这个库了。
趋势
炒作也好，讨论也好，保持大家对这个库的新鲜关注非常重要，因为这能连带的让这个库做好上面说的很多点。
但注意过分的炒作，可能会降低这个库的稳定性，毕竟在用户爆发式增长之前，最好有一部分当小白鼠。
搬家成本
这个是作者补充的比较重要的一天：如果哪天不用这个库了，换成别的成本有多大？
这方面测试库做的很好，很多主流测试库比如 Jest、Ava、Mocha、Jasmine 等之间都有互转的脚本，业界基本达成了一些共识和规范。
比较坑的是 React、Vue、Angluar，使用之后你基本就被绑定了，至今没有谁可以无缝做各大框架的迁移。当然 JS 的年龄还很短，而且说不好未来还会被新语言、技术、容器颠覆而成为历史，标准化不是做不到而是需要时间，也许就在十几年之后，但是今天就是做不到。
3 总结
下次技术选型讨论时，可以拿出规则一条一条比对了！
然后技术选型只是基础库，利用这些基础可以维护好自己的开源库，把更多时间用在创造业务价值上。
仔细思考就会发现，程序员开发的工具库也适合点线面体的概念。一个库 react-button 就是一个点，而它所在的线 react 如果被人抛弃了，无数个 react-xxx 也会翻船。而 react、vue、angluar 这些线都在 js 引擎这个面上，当可以用 C# 写 WebAssembly 时，Reason、Blazor、Dart 就会逐渐成为浏览器的主角，react 之类的库统统要回炉打造。而当未来人机互联不需要浏览器作为媒介时，js 引擎这个面依附的体 - 人机交互场景也被打翻了，这一浪又会引起多大的变化。
所以技术选型是为了解决当下业务问题，仔细考虑好几个因素，适合解决业务场景就足够了。