精读《12 个评估 JS 库你须要关心的事》

1 引言

做者给出了从 12 个角度全面分析 JS 库的可用性，分别是：

1. 特性。
2. 稳定性。
3. 性能。
4. 包生态。
5. 社区。
6. 学习曲线。
7. 文档。
8. 工具。
9. 发展历史。
10. 团队。
11. 兼容性。
12. 趋势。

下面总结一下做者的观点。

2 概述 & 精读

特性

当你调研一个 JS 库，功能固然是最重要的，就比如 React 的用于开发 UI 界面很是方便，这是流行起来的一部分因素。

但同时 React 解决的问题很聚焦，因而把例如 Router 和 Store 部分交给社区给解决方案，这就让 Vue 的官方维护生态模式发展了起来。但这更多取决于你的偏好，像 lodash 这种精简的库也会长盛不衰，重要的是这个库提供的能力是否解决了你的业务问题。

评分：A - 化腐朽为神奇。B - 更优雅的解决方案。C - 比现有方案差。

稳定性

这个库若是常常出 BUG，那显然没法在生产环境使用。最好通过严格的测试，保证这个库必定不会出错，这样咱们就能够专心排查业务的问题了。

评分：A - BUG 不多，方便调试。B - 不会影响你的稳定性，好比出 BUG 几率和你的业务代码相近。C - 引入该库会让你背线上故障。

性能

若是让用户 15 秒才能打开网页，那一切都是徒劳。

拿 PReact 为例子，为何 API 相同的轮子能够活下来？由于体积小，并且 PReact 把宣传重点放在性能上。

如何一句话说明白你不是在造无用的轮子？性能更好。

评分：A - 小体积，高性能，支持各类黑科技特性好比 Tree shaking。B - 对性能没有影响。C - 致使性能下降。

包生态

用过 monaco-editor 吗？你们都在用 webpack 但它却走 amd 路线，我不知道你用什么方法让它支持 commonjs 的，但这必定耽误了你很多时间。

包生态包括第三方包的成熟度，包的使用难易度，支持多少种模块化方案，是否支持 TS，有没有管理好本身的依赖等等。

开箱即用是最好的，有长期维护组织的更佳。

同时不要有太多相互竞争的社区方案为佳。好比工具库用 lodash 这很容易，但 React 数据流方案选择哪一个？太多的竞争对手不断写软文抢夺用户（程序员）的注意力，试图说服他们加班重构。

评分：A - 方案惟一且生态运做良好，维护记录标准规范且顺畅。B - 不少新晋网红包，且竞争选择多。C - 没有人给你作包，想用要本身封装。

社区

可否快速在 Stack Overflow 搜到问题的答案能反映出社区的活跃度，不管是官方文档仍是第三方进行的问答。

社区越活跃，帮你提早踩的坑就越多，若是你遇到一个你们都没有遇到过的问题，并不表明你用得有多深度，而可能你根本就用错库了。

评分：A - 各类论坛每日都很活跃，Github issue 问题日清。B - 论坛/聊天室不太活跃。C - 除了做者自吹的文档，再也找不到任何相关信息了。

学习曲线

不要觉得把库功能作的强大，就算难用点也会有用户跪舔，这是幻觉。

Vue 之因此那么火爆，是由于原生 HTML 的门槛比 JSX 低，而使用 React 的用户每每都以为 JSX 比 HTML 门槛低。我也不知道该怎么描述，从 JS 能够产生一切的角度，学习 HTML 反而被认为是高门槛的体现。

因此认清现实，JSX Star 多并非其理论有多先进（理论确实先进），而是不少人以为总体学习维护成本比 HTML 低。

评分：A - 一天就能成为这个库的熟练搬砖工。B - 浪费了一周时间才能投入使用。C - 学了一周才发现以前的理解是错的，并且认识到这只是个开始。

文档

写文档的人通常都是库的做者，这种人通常经验会比较丰富，写起文档通常不会考虑初学者的感觉，因此找到一份对初学者友好的文档仍是挺不容易的。

对于库的维护者，要站在初学者角度去写文档，站在使用者角度，若是文档开头就看不懂的话，最好尽早换个文档或者换个库。

评分：A - 专门维护文档站点、视频、图片、示例项目，再好一点的话能够有专门基金会组织编程比赛，经过某三岁孩子能够一天入门强力影射技术生态的完备性。B - 有最基本的 Readme 和 API 文档。C - Readme 写的是 Create react app，其余的只能查源码了。

工具

工具能够从多个维度体现出这个库的优点，首先是确实带来了使用方便，其次展现了团队维护实力的雄厚（精力溢出到能够作周边工具了）。

Redux 之因此这么火，Redux dev tools 功不可没，笔者读过一些心理学书籍，也经历过一些技术选型，看到 Redux dev tools 的图形化界面后，大脑由于受到视觉冲击比理性的逻辑思考大太多，潜意识里给 Redux 加了很多分，致使讨论结果都变得不太理性了。

若是你的库能图形化表达，或者作一个 PPT 或者辅助工具，那必定会大大加分。（React chrome 插件在打开 react 作的网页时亮起来真的很酷，这个勋章颇有仪式感，以致于我不想换一个框架）

评分：A - 两个以上的工具，包括浏览器拓展、代码编辑器拓展、CLI 工具或者 SaaS 服务，实力碾压的话，会有许多花哨的辅助工具出现。B - 一个工具。C - 没有工具。

发展历史

一个 Star 10K 的库，若是最先提交是十天前，就算不是刷的也最好也不要用，由于不知道哪天做者就再也不维护了。

历史越悠久的库使用风险越小，除非它所在的面被淘汰（技术栈、生态、编程语言等等）。

评分：A - 4 年以上历史，有权威认证。B - 1-4 年历史，已经有很多人使用过了。C - 做者本身都没用过就安利你用到线上去。

团队

看谁是这个库背后的男人。大公司普遍使用的开源库，而且有必定国际影响力，并且大厂也有成功开源历史经验的话，就会增长说服力。

但 Vue 就是个例外，几乎凭尤大一人之力打造，对这种状况，笔者想说的是，一个真心热爱技术并践行全职维护的人，也许比一个背着 KPI 的团队维护副产品更靠谱。

评分：A - 一线大厂，品质权威认证。B - 中型团队维护，而且有清晰的分工记录。C - 工做之余顺便开源出去，就没打算对这个库负责。

兼容性

除了浏览器兼容性，库 API 的兼容性也很是重要。当你很容易联系到做者，而且改动 API 的建议被很快采纳时，你就要当心了。

React Router 3 -> 4 升级带来的阵痛你们都有体会过，babel7 放弃 stage 0-4 也带来很多吐槽，Angular1 和 Angular2 的区分直接让不少人粉转黑了。虽然许多时候频繁的更新是为了增添新功能，但若是带来 API 兼容问题，反而会招来反感。

假如大家团队维护的 10 年间，由于某个库做者很是勤奋的更新致使以时间为维度，均匀分布了数十种不一样的版本，你会发誓下一个项目再也不使用这个库了。

评分：A - 老是能兼容升级，实在不行就提早警告并告知在某个版本会废弃，并提供迁移工具，好比 React。B - 有 Break Change 可是文档把升级改动写的很清楚。C - 忽然到来的小版本升级让你不得不重构以前的调用代码。

趋势

炒做也好，讨论也好，保持你们对这个库的新鲜关注很是重要，由于这能连带的让这个库作好上面说的不少点。

但注意过度的炒做，可能会下降这个库的稳定性，毕竟在用户爆发式增加以前，最好有一部分当小白鼠。

评分：A - 是 HackNews 的明星话题，Star 成千上万，各类会议以此为名（Vue conf，React conf）。B - 几百 Star，有一些讨论。C - 别看如今 Star 少，早晚有一天我会超过那啥那啥。

搬家成本

这个是做者补充的比较重要的一天：若是哪天不用这个库了，换成别的成本有多大？

这方面测试库作的很好，不少主流测试库好比 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 引擎这个面依附的体 - 人机交互场景也被打翻了，这一浪又会引发多大的变化。

因此技术选型是为了解决当下业务问题，仔细考虑好几个因素，适合解决业务场景就足够了。

4 更多讨论

讨论地址是： 精读《12 个评估 JS 库你须要关心的事》 · Issue #104 · dt-fe/weekly

若是你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。