共计 4015 个字符，预计需要花费 11 分钟才能阅读完成。
您如何知道一项新技术是否值得投入时间？
对于今年的 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 的规模！
可扩展性：该技术对大型项目的效果如何？
采用：目前还有谁在使用该技术？
兼容性：该技术与其他现有技术的合作程度如何？
解耦：如果你想停止使用它，从技术迁移出来有多容易？
