选择JavaScript开源库时，你须要考虑这些问题

选择JavaScript开源库时，你须要考虑这些问题

做者｜Sacha Greif
译者｜无明
对于 2018 年的 JavaScript 状态调查，我想深刻挖掘一下。我不只想知道人们都在使用哪些工具和库，还想知道他们为何选择它们。通过一番研究，我开发出了一个评分系统，能够将它做为技术选型的衡量标准。

12 因素测验

为了让你可以更好地对各类库打分，我准备了一个快速测验，将引导你完成 12 个因素的评分，而后给出建议。若是你不肯定要评估什么，只需选择你熟悉的库（如 React、Vue、jQuery 等），看看它们的得分状况如何。
测验地址：https://stateofjs.typeform.com/to/hTRAcc。

或者，你能够继续往下读，了解每一个因素的详细信息，并了解如何应用这些因素。
这 12 个因素分别是：特性、稳定性、性能、库生态系统、社区、学习曲线、文档、工具、历史、支持团队、兼容性、发展势头。我将解释每一个因素的重要性，并为你提供一个评分网格，向你展现如何评估它们。

1. 特性

特性是你在选择任何一项技术时须要考虑的第一个因素。
关键在于要有个度。React 多是目前最流行的前端库，但人们抱怨它作得还不够，它将路由和状态管理等内容留给了第三方库，如 React-Router 和 Redux。
然而，这些倒是 Vue（React 最大的竞争对手）最吸引人的地方。Vue 为这些常见用例提供了官方的解决方案，从而得到大量开发者的支持。
但若是作得太过头了，试图解决全部的问题，就有可能会获得一个臃肿又复杂的框架。
有时候，恰到好处就是最好的。像 Lodash 或 Ramda 这样的库可让你用简洁的函数表达式替换乱糟糟的 for 循环嵌套，这足以让它们成为无价的工具。

评分系统

A：作到以前没法作到的事情。
B：可以让你以更好的方式作以前一样的事情。
C：能作的事情比现有解决方案少。

2. 稳定性

你使用的框架可能很优雅，功能很全面，但若是开发人员每两三分钟就会犯一次错误，那么整体上并不会给你带来多少好处。
所以，当前 JavaScript 生态系统中的不少工具都专一于为技术栈带来稳定性和安全性。看看 TypeScript 和 Flow 的成功就知道了，甚至是 Reason。
在数据层面，GraphQL 的类型系统也有助于确保一切顺利运行。

评分系统

A：更少的错误，问题变得更容易调试和解决。
B：采用该技术不会对软件的稳定性产生影响。
C：采用该技术的直接后果是出现了新的错误和问题。

3. 性能

若是你曾经练过武，就会知道速度才是最重要的，而不是力量。
一样，若是你的应用程序须要 15 秒才能加载完毕，那么全部的功能都变得毫无心义，由于没有耐心的用户早已关掉了浏览器标签。能够说，这场仗还没开始打，你就失败了！
在 JavaScript 生态系统中，Preact 就是一个很好的关注速度的例子：它的 API 与 React 彻底相同，因此它不会试图在功能上与 React 展开竞争。可是，与 React 相比，Preact 更轻量，加载速度更快，能够节省宝贵的毫秒数，并提升 Web 应用程序的性能。

评分系统

A：更轻的捆绑，更快的加载速度或其余性能改进。
B：采用该技术不会对你的软件性能产生影响。
C：采用该技术会显著下降应用程序的速度。

4. 库生态系统

在采用一项新技术以前，要先看看它的生态系统。
一个充满活力的库生态系统不只能够节省大量时间，由于它可让你复用其余人的工做成果，但这也代表这项技术已经达到了必定的成熟度水平。所以，维护活跃度是开发者应该长期采用这项技术的最佳标志之一。

评分系统

A：生态系统对人们广泛关注的问题有明确的解决方案，维护积极且文档齐全。
B：拥有诸多竞争选项的萌芽库生态系统。
C：没有库生态系统可言，须要作大量的手动工做。

5. 社区

另外一个要考虑的因素是社区。在遇到问题时，论坛或 Slack 频道能够提供大量的帮助。

Spectrum 是介于聊天室和传统论坛之间的一种沟通方式
Stack Overflow 也是一个能够找到不少问题答案的网站。固然，维护良好的 GitHub 问题页面也是必需的！

评分系统

A：进行平常交流的论坛或聊天室（Slack、Discord 等），一天内能够获得解决的 GitHub 问题。不少人回答了 Stack Overflow 的问题。
B：不活跃的论坛或聊天室。
C：除 GitHub 以外没有其余社区。

6. 学习曲线

简单的学习曲线意味着开发人员更有可能尝试使用你的框架或库。人们很容易认为，若是一项技术真正具备颠覆性，他们就会克服一切障碍来学习它，但一般事实并不是如此。
一个密切相关（但有时却相反）的概念是“采用”曲线。Meteor 在刚出现时，很是易于使用（至少与现有替代品相比），但它要求你必须使用它的整个技术栈，因此要将它应用在已有的项目中很困难。
React 以它的陡峭的学习曲线而闻名：对于习惯了分离 HTML 和 JavaScript 的开发人员来讲，不得不使用 JSX。相比之下，Vue 更容易上手，不须要你改变对前端编码的思考方式。

评分系统

A：能够在一天内上手。
B：在能够带来生产力以前须要大约一周时间。
C：须要一周以上的时间来学习基础知识。

7. 文档

简单的学习曲线意味着它须要提供出色的文档，但要真正作到这一点并不容易，由于撰写文档的人一般是经验最丰富的人，也就是说他们早也脱离了新开发者的状态，因此不必定能重新开发者的角度来撰写文档。
所以，撰写好的文档要求你暂时忘记你所知道的一切，并重新手的角度思考问题。

Vue.js 的文档通过精心的设计和编写（https://vuejs.org/v2/guide/）
它还要求你预测常见的问题，了解用户的心理模型，最重要的是在代码库发生变化时保持最新状态！作到这些须要宝贵的时间......
所以，你能够理解为何好的文档实际上是既罕见又有价值的东西！

8. 工具

就像文档同样，工具对于一些维护者来讲看起来彷佛是次要的，但实际上对于任何一项技术的普及和成功来讲都相当重要。

Redux 的 DevTools（https://github.com/zalmoxisus/redux-devtools-extension）
我相信 Redux 取得成功的一个重要缘由是它提供了优秀的 DevTools 浏览器扩展，让你能够以用户友好的方式可视化 Redux 存储和操做。一样，VS Code 对 TypeScript 强大的支持也为它的普遍采用创造了奇迹。

评分系统

A：拥有两个或多个：浏览器扩展、文本编辑器扩展、CLI 实用程序、专门的第三方 SaaS 服务。
B：拥有其中之一：浏览器扩展、文本编辑器扩展、CLI 实用程序、专门的第三方 SaaS 服务。
C：没有外部工具。

9. 历史

毕竟，即便是最优雅、文档化最好的库也会被历史所遗忘，由于若是它只存在了六个月，也只是昙花一现而已。

Express：即便过了这么多年，仍然是一个有力的竞争者（https://expressjs.com/）
所以，具备良好历史记录的东西难以被战胜。Express 就是其中的一个例子：它最初于 2010 年发布，但如今仍然被认为是首选的 Node.js 服务器框架，尽管 JavaScript 生态系统经历了快速的发展。

评分系统

A：已经存在四年多，被知名的技术公司采用。
B：已经存在了 1 至 4 年，被早期采用者和小规模技术公司采用。
C：存在不到一年，尚未真正被采用。

10. 支持团队

并不是全部项目都有悠久的历史。对于一个全新的库，你如何判断它的潜力？一种可靠的方式是看看它背后的支持团队。
当 React 刚出现时，光是其背后的公司是 Facebook 就能够做为尝试一下的理由。后来 Facebook 继续发布了 Relay 和 GraphQL，代表 React 的成功并非侥幸！

谷歌开源：超过 2000 个项目，涵盖了桌面和移动等平台的开发（https://opensource.google.com/）
大公司有更多的资源能够投入：即便发布了更新的不兼容版本，谷歌也可以继续维护原有的 Angular.js。
固然，这并表示独立维护者就没法创造出重大的创新。Vue.js 的诞生就是在这样的状况下诞生的，更不用说其余 99％的开源软件了。

评分系统

A：由一家拥有专门开源团队的大公司维护。
B：由一个中等规模的工程师团队维护。
C：独立维护者。

11. 兼容性

采用尖端库的好处在于它们一般发展得很是快。惋惜的是，这也多是一个重大的缺点！
快速演进也可能意味着频繁的重大变动，由于新的最佳实践取代了旧的模式，早期采用者须要付出重构成本。
当 React Router 决定在版本 3 和版本 4 之间彻底改变 API 时，致使了人们的不少抱怨。而当 Angular 从 Angular.js 切换到新的“Angular”时，也是如此。
当你刚开始一个新项目时，频繁更新颇有趣，也很使人兴奋，但一旦应用程序进入生产环境，你最不但愿的事情是每次发布新版本的库都须要花费数周的重构和调试时间。

评分系统

A：更新大可能是向后兼容的，若是弃用会发出警告，花两年或更长时间维护不兼容的旧版本。
B：确实发生了突破性的变动，但提供了很好的文档，并以渐进的方式推出。
C：频繁发布重大更新，须要进行大量重构，并且没有提供适当的指南。

12. 发展势头

最后一个很重要的因素是发展势头，换句话说就是炒做。
炒做一般被认为是一件坏事（“不要成为炒做的受害者”），但事实并不是老是如此。
有了足够的炒做动力，一个新的软件项目才能够吸引更多的用户和更多的贡献者，这意味着能够更快地找到并修复错误，库生态系统能够获得发展，每一个人最终都会变得更好。

JavaScript Rising Stars，绘制了 JavaScript 流行库的增加状况（https://risingstars.js.org/2017/en/）
固然，硬币有另一面：过早进行过多的炒做可能会让潜在用户面临一个充满问题的不完整版本，而你一般只有一次机会给别人留下良好的第一印象。

评分系统

A：超过 9000 个 Star 的炒做水平：Hacker News 的头条，成千上万的 GitHub Star 数，在主要技术大会议上被说起。
B：最初推出时人们有一些兴趣，数百个 GitHub Star 数。
C：孤独的开发者在默默无闻地辛勤劳做，总有一天我会向人们展现一切!

更多因素

有些人提出了一些值得关注的其余重要因素，或许我须要考虑将它们包含在 2.0 的评分制中！
伸缩性：是否适用于大型项目。采用：目前还有谁在使用该技术？兼容性：该技术与其余现有技术的兼容性如何？解耦：若是你不想再用它，迁移有多容易？
案例研究：Apollo 客户端
让咱们用一个真实的库来测试这个评分系统：Apollo 客户端。

Apollo 客户端（https://www.apollographql.com/client/）
Apollo 是一个 GraphQL 客户端，换句话说，它是一个库，查询 GraphQL 端点并将数据加载到客户端上。它还负责处理缓存之类的东西，确保数据不会重复，并将数据发送给前端库。
让咱们来看看它在评分系统中的表现！
特性：B
Apollo 为咱们提供了更好的查询数据的方法，所以它更多地是对现有工具的逐步改进。
稳定性：A
采用 Apollo 和 GraphQL 确实能够更容易地推断数据和追踪问题。
性能：B
Apollo 提供了优化数据加载的工具，但整体上不会对应用程序的性能产生巨大影响。
库生态系统：A
Apollo 的包系统被称为 links，这些 link 提供了额外的功能。
社区：B
Apollo 有一个很是活跃的 Slack 频道，但根据个人经验，有时候问题可能没法获得回答，很可贵到繁忙的核心团队成员的回复。
学习曲线：B
学习 Apollo 的全部细节可能会是一个挑战，特别是若是你同时在学习如何使用 GraphQL。
文档：A
为多个前端框架以及示例代码库提供了良好的文档。
工具：A
提供了浏览器扩展和专门的度量指标平台。
历史：B
Apollo 自己很年轻，GraphQL 也是如此。
支持团队：A
资金充足的高竞争力团队，具备其余开源项目（Meteor）的开发经验。
兼容性：B
从 v1 到 v2 带来了重大变动，但整体上具备良好的稳定性和向后兼容性。
发展势头：B
Apollo 可能还不是一个家喻户晓的项目，但它仍然是利基的主导者，尽管有 Relay 先声夺人。
整体成绩：A
得分 29（满分 36），可见 Apollo 最终表现得很是好！即便还有须要改进的地方，但咱们也很容易理解为何那些须要可靠方法来处理 GraphQL 数据的团队会采用它。

其余方法

NPMS 已经实现了一个相似的评分系统（https://npms.io/about），能够查看 GitHub 和 NPM 的数据。这个系统的评分比较客观，但没有涵盖文档或社区等方面的内容。
在原始数据方面，你还能够经过 NPM Trends 得到一些很酷的统计数据：

NPM Trends（https://www.npmtrends.com/）
经过 Best of JS 查看当前哪些库最流行：

Best of Trends（https://bestofjs.org/）
固然，还有去年的 JavaScript 状态调查：

JavaScript 2017 状态调查（https://2017.stateofjs.com/）
英文原文
https://medium.freecodecamp.org/the-12-things-you-need-to-consider-when-evaluating-any-new-javascript-library-3908c4ed3f49