引用一个 JS 库或者做技术选型的时候，往往会关注一些可用性相关的东西，下面列出来 12 个观点去分析 JS 库的理想属性
- 特性
- 稳定性
- 性能
- 包生态
- 社区
- 学习曲线
- 文档
- 工具
- 发展历史
- 团队
- 兼容性
- 趋势
- 上面十二个点足以表达出一个框架或者一个库是否能被选用并且较后获得持续发展
- 特性
- 为什么需要选这个库，是因为某些特性功能能给予我们帮助，这也是流行起来的一些因素，能解决业务问题的都是好库
- 稳定性
- 在生产环境下 BUG 率比较低，拥有良好的测试、测试用例，较高的测试覆盖率，能够减轻在库/框架中遇到的 bug，减少排错时间，专心业务方向的问题排查。
- 性能
- 相同的框架上，如果性能快上一倍，那么可能会优先选择较快的一个框架，当然这个是其中一个选型的因素。
- 体积小，性能好，Tree shaking , esbuild 等等
- 包生态
- 当前包的第三方引用库，打包方式(webpack amd cjs es module) polyfill，生态维护良好，维护 release 流程较为标准，这也作为库选型的一个比较重要的方向
- 社区
- 好比如 swiper，写的时候能不能在开源提问社区中找到问题反馈的解决方案，说明这个库是有人在大量使用提出问题并且解决问题的，社区中不同语种的开发者也会衍生出不同的语言开发者翻译社区或者论坛，gihub issue / chatter 等等
- 学习曲线
- 这一点尤其是会给初学者考虑的一点，刚开始学的时候如果框架的上手难度太大会令人十分崩溃，从而放弃对框架的使用，对于某些概念理论难以理解也会损失一部分用户。
- 文档
- 文档写的好，也是使用者选择的一个关注点，库的作者也十分重视对文档的编写，文档有可能不是给初学者准备的，所以像 Vue 这种对新手比较友好的文档还是且行且珍惜吧。基本的使用文档、API 文档解释注释，示例能保证有源源不断的使用者加入生态社区的建设。
- 工具
- 这里的工具是指周边生态工具的支持，如果核心团队成员有剩余的精力可以写相关的工具 (如 dev tools 等等) 让调试等等工作变得简单轻松不少，大家也十分乐意见到这种情况的出现。(浏览器拓展、CLI、语法高亮提示拓展等等)
- 发展历史
- 持续发展的库才是我们比较信任的开源三方库，开源是一件不断改进的事情，create a repository is easy, but continuous making progress is difficult, 如果一个库积压着一堆 issue 和一堆 pr 未处理，我会觉得作者可能时间精力已经没有放在项目上面了，同时使用者遇到 BUG 的时候也没能得到快速的解决，源头上比较难解决出现的问题，不予信任。长远的看，库的存活时间越长(早期创建项目至今仍有 issue 和 pr 的响应)，可信任程度越高
- 团队
- 我们所广泛使用的库，一定是经过推广并且有一定影响力的人进行布道实践的，又或者是大厂内部开源然后孵化外部使用同时也得到认可的，极少可能是 KPI 项目，个人来说比较讨厌 KPI 做出的轮子，这样可持续性较低并且目标不纯粹，热爱开源的人一定是对软件事业有一定抱负的，并且是迫切想改变现有状况的人。
- 兼容性
- 浏览器兼容和 API 兼容也十分重要(polyfill) 三方依赖兼容 ，对于某个框架升级带来的 breaking change 需要谨慎了，破坏性改动太大必然给你打来升级的巨大成本，比如重构或者重写利用某个 API 实现的功能
- 趋势
- 像现在大前端的趋势下，js runtime 愈发强大，同时也可以使用不同的语言编译成 js 或者从 js 编译为不同的环境去运行，让 web 充满生机，各种会议论坛争相分享新技术，用户爆发增长之前肯定会有一批开发者提前去体验新技术并且参数改进，这一批人虽然是小白鼠但是也是最早能吃到趋势红利的人。
- 搬家成本
- 比较重要的一点，像 snowpack 一样，如果作者对于此库的维护精力减少从而去使用同方向下更优秀的库(vite) ，你的切换成本有多大，对于强绑定性的框架而言，一旦大框架废弃了，意味着以后的每一个行动都举步维艰，因为 JS 的年龄还是比较小的，所以以后有任何新的语言，技术，容器替代出现，我是一点都不奇怪并且会积极参与转型的，不过这对一个企业而言是否能承担起这个风险？留给时间说话把。
- 技术选型参照以上十二种方向做思考应该没什么太大的问题了，这些选型只对于基础库有比较大的帮助，业务价值还是需要个人花时间打磨的，这些只是前提工作和持续性改进的方向，对于个人的开源可能帮助会更大。
- 工程师而言，点线面的概念也要十分清晰，要意识到现在正在做的一些工具可能只是为某个线去服务的，如果当前线断掉了，线上的点是否会因为线的断掉而散落，同时面的变化也会影响下两层的细化行为。
- 不过当下的技术选型只是为了解决业务问题，所以只需要关注当下的几个痛点，解决业务场景的问题就可以了