您如何知道一项新技术是否值得投入时间？
对于今年的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的规模！
- 可扩展性：该技术对大型项目的效果如何？
- 采用：目前还有谁在使用该技术？
- 兼容性：该技术与其他现有技术的合作程度如何？
- 解耦：如果你想停止使用它，从技术迁移出来有多容易？
