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

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

clipboard.png

对于今年的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的规模!

  • 可扩展性:该技术对大型项目的效果如何?
  • 采用:目前还有谁在使用该技术?
  • 兼容性:该技术与其他现有技术的合作程度如何?
  • 解耦:如果你想停止使用它,从技术迁移出来有多容易?

Leave a Reply

Your email address will not be published. Required fields are marked *