在使用新的JavaScript库时须要考虑的12件事

您如何知道一项新技术是否值得投入时间？

对于今年的JavaScript状态调查，我想深刻挖掘一下，不只知道人们正在使用哪些工具和库，还要为何他们选择使用它们。

这意味着我必须找到一种方法将我的偏好转化为冷酷的数据。通过一些研究，我提出了12分制，涵盖了挑选和使用任何技术的主要方面。

在此邀请你参加测试 ➡️ Take the 12-Factor Quiz
若是您不肯定要评估什么，只需在您熟悉的库（React，Vue，jQuery ......）上进行评！
也能够在http://stateofjs.com/ 上面查看一下往年的结果
若是您想贡献并帮助肯定JavaScript生态系统的最新趋势，参加调查！

如今回到12分制。

因素

这里有一张列表：

• 🕹️ 特征
• 🐞 稳定性
• ⚡ 性能
• 🎁 Package 生态系统
• 🌎 社区
• 👶 学习曲线
• 📖 文档
• 🔧 外部辅助工具
• 🏛️ 跟踪记录
• 👫 团队
• ⚖️ 兼容性
• 📈讨论度

我将解释每一个因素的重要性，并为您提供一个评分网格，向您展现如何评估它。咱们来看看清单吧！

🕹️ 特征

你选择任何技术的第一个缘由多是它的做用。

但这里的关键问题是你到底是须要这个库的什么。React多是目前最流行的前端库，但仍是有人以为它作的不够好，由于它将路由和状态管理等内容留给第三方方库，如React-Router和Redux。

事实上，这是React最大竞争对手Vue的吸引力的一个重要部分。经过为这些常见用例提供官方软件包，它能够提供更全面的解决方案并得到大量支持。

因此有时候，最简单的方法就是弄清楚咱们究竟须要什么。像Lodash或Ramda这样的库让你能够用简洁的函数表达式替换乱糟糟的嵌套for循环，这足以使它们成为无价的工具。

一样，这一切都是为了寻找合适的！

评分系统

• A: 是否能作到之前作不到的事。
• B: 让你作与之前相同的事情，但以更好的方式。
• C:是否优于当前的解决方案。

🐞 稳定性

您能够拥有最优雅，功能全面的框架，但若是开发人员每两分钟发生一次错误，却也一样让人感到崩溃。

所以，当前JavaScript生态系统中的许多工具都专一于为堆栈添加稳定性和安全性。看TypeScript和Flow的成功，甚至是Reason等语言。

在数据层方面，GraphQL的类型系统也有助于确保一切顺利运行。

评分系统

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

⚡ 性能

若是你曾经训练过武术，你就会知道你能够拥有的最好的属性之一是speed，而不是力量。

一样，若是您的应用须要15秒才能加载，那么世界上的全部功能都无济于事。到那个时候，用户已经关闭了标签，你甚至在它开始以前就已经失去了战斗！

在JavaScript生态系统中，只需看看Preact就能够看到关注速度的一个例子：它的API与React彻底相同，因此它并不试图在功能强度上展开竞争。可是，与React相比，它重量更轻，加载速度更快，能够节省宝贵的毫秒数并提升webapp的性能。

评分系统

• A: 更小的体积，更快的加载时间或其余性能改进。
• B: 采用该技术不会对您的软件性能产生影响。
• C: 采用该技术能够显着下降您的应用程序速度。

🎁 Package 生态系统

在投资任何新技术以前，重要的是要看看围绕它开发的生态系统。

一个充满活力的软件包生态系统不只能够节省大量时间，这也代表该技术已经达到了必定的成熟度水平。出于这个缘由，维护良好的第三方软件包是开发人员长期采用技术的最佳标志之一。

评分系统

• A: 生态系统对共同关注的问题有明确的解决方案;第三方软件包维护良好且文档齐全。
• B: 具备许多竞争新选择的萌芽package生态系统。
• C: 没有package生态系统可言，须要大量的手工工做。

🌎 社区

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

查找Stack Overflow现有的存储库也颇有帮助。固然，维护良好的GitHub问题页面是必须的！

评分系统

• A: 论坛和/或聊天室（Slack / Discord / etc。）平常活动，GitHub问题在一天内获得解决。许多人回答了Stack Overflow问题。
• B: 论坛和/或聊天室，不常常活动。
• C: 除了GitHub以外没有社区。

👶 学习曲线

简单的学习曲线使开发人员更有可能为您的框架或库提供一个机会。人们很容易认为，若是一项技术真正具备破坏性，人们就会克服任何障碍，但这一般都不是真的。

一个密切相关（但有时相反）的概念是“采用”曲线。首次推出时，[Meteor]（http://meteor.com/）很是易于使用（至少与现有替代方案相比），但它要求您当即采用整个堆栈，所以很难实现现有项目。

React也以其粗略的学习曲线而闻名：对于用于分离HTML和JavaScript的开发人员来讲，不得不使用JSX可能很难。另外一方面，Vue变得更容易，而没必要从新思考您对前端编码的思考方式。

评分系统

• A: 能够在一天内开始。
• B: 在提升工做效率以前须要大约一周
• C: 超过一周须要学习基础知识。

📖 文档

简单学习曲线的一个重要部分就是拥有出色的文档。这比听起来更难实现，由于撰写文档的人一般是经验最丰富的人。

所以，编写好的文档须要忘记你原有的技术知识，并让本身置身于发现你的技术之中。

它还须要预测常见问题，了解用户的心理模型，最重要的是在代码库发生变化时保持最新状态！全部这些都须要宝贵的时间......

鉴于全部这些因素，您能够理解为何好的文档是一种罕见且有价值的东西！

评分系统

• A: 专用文档站点，截屏视频，示例项目，教程，API文档和评论良好的代码。
• B: 基本自述文件和API文档。
• C: 很是简洁自述，了解如何使用库的惟一方法是查看其代码。

🔧 外部辅助工具

就像文档同样，工具是这些事情中的一个，对于某些维护者来讲可能看起来像是次要的，但实际上对于任何技术的普及和成功都相当重要。

我相信Redux成功背后的一个重要缘由是其使人惊叹的Devtools浏览器扩展，它容许您以很是用户友好的方式可视化Redux存储和操做。一样，VS Code的强大TypeScript支持也为它的采用创造了奇迹。

评分系统

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

🏛️ 跟踪记录

由于若是一个库只存在了六个月，那就不过是昙花一现了。

咱们均可以讲述采用“下一件大事”的故事，只是回到好老的Rails / PHP / 在这里插入尝试真实的技术 当事情开始恶化时。

出于这个缘由，没有什么能够打破坚实的记录。Express是其中一个例子：它最初是在2010年发布的，但仍然被认为是默认的Node.js服务器框架，尽管JavaScript生态系统的发展速度很快。

评分系统

• A: 已经有4年多的时间，经过了主要公司和知名的技术咨询公司。
• B: 已经存在了1 - 4年，被早期采用者和较小规模的咨询公司使用。
• C: 已经存在不到一年，尚未真正的采用。

👫 团队

并不是全部项目都有可跟踪的记录。当package是全新的，你如何判断它的潜力？一种可靠的方式来看看它背后的人。

当React第一次出现时，因为其背后的团队是Facebook，因此给人一种至少要尝试一下的感受。而后Facebook继续发布Relay和GraphQL，代表React的成功不是侥幸！

更大的公司也有更多的投资资源：即便发布了更新的，不兼容的版本，谷歌也可以继续保持原有的Angular.js。

固然，这并不意味着单独的维护者就没法创造重大创新。毕竟有Vue.js这样的例子存在，更不用说99％的开源软件了。

评分系统

• A: 由一家拥有专门的开源团队的大公司维护。
• B: 由中型工程师团队维护，拥有坚实的我的记录。
• C: 孤独的维护者独立工做。

⚖️ 兼容性

采用尖端库的好处在于它们一般发展得很是快。可悲的是，这也多是一个重大的缺点！

快速改进率也意味着频繁的突破性变化，由于新的最佳实践取代了旧的模式，使早期采用者付出了重构成本。

React Router当他们决定在版本3和版本4之间彻底改变他们的API时，产生了不少抱怨。Angular当他们从Angular.js切换到新的“只是Angular”时，也是如此。

当你刚开始一个新项目时，常常更新会很使人兴奋，可是一旦你的应用程序启动并在生产中运行，你并不会想要每次都由于库的更新而其改动线上的代码。

评分系统

• A: 更新大可能是向后兼容的，弃用是经过警告处理的，不兼容的旧版本维护两年或更长时间。
• B: 确实发生了重大变革，但有很好的文件记录，并逐步推出。
• C: 没有适当的指导，常常须要进行重大更新。

📈 讨论度

最后但一样重要的是，势头。换句话说，炒做。

炒做一般被认为是一件坏事（“不要成为炒做的牺牲品”），做为风格超过实质的指标。但并不是老是如此。

有了足够的动力，一个新的软件项目能够吸引更多的用户和更多的贡献者，这意味着能够更快地找到和修复错误，一个包生态系统能够开发，每一个人最终都会变得更好。

可是，是的，还有硬币的另外一面：过早炒做太多可能会让潜在用户面临一个充满问题的未完成版本，并将其完全解决。就像他们说的那样，你只有一次机会给人留下第一印象。

评分系统

• A: 炒做超过9000：黑客新闻的顶部，成千上万的GitHub star，在主要会议上进行会谈。
• B: 最初推出的一些兴趣，数百名GitHub明星。
• C: 孤独的开发和辛苦工做。

更新：更多因素

大家中的一些人提出了一些更重要的因素。要考虑潜在版本2.0的规模！

• 可扩展性：该技术对大型项目的效果如何？
• 采用：目前还有谁在使用该技术？
• 兼容性：该技术与其余现有技术的合做程度如何？
• 解耦：若是你想中止使用它，从技术迁移出来有多容易？