为什么像LoDash或UnderScore这样的Javascript库比map、reduce或filter这样的原始JS

Why are Javascript libraries like LoDash or UnderScore utilized more often than raw JS functions like map, reduce, or filter

本文关键字：reduce filter 原始 JS map 库比 LoDash 为什么 Javascript UnderScore 更新时间：2023-09-26

我倾向于发现，当直接的JS函数完成这项工作时，所列出的库会被更频繁地使用。我相信加载额外的库总是会增加更多的加载时间，所以我很好奇为什么原始JS函数没有被更频繁地使用。

在该语言中，纯JS函数与后期编写的辅助函数相比，是否有任何速度优势？

额外的库加载时间难道不会损失预制库的好处吗？

通常在原始JS上使用框架是为了兼容性。浏览器之间、不同版本的浏览器之间的Javascript存在差异，并且有些实现是不完整的。像下划线之类的工具有助于消除兼容性问题，在代码和原始JS之间提供一个公共层。

如果你可以消除使用不同浏览器的可能性，那么当然可以继续使用RawJS，但从长远来看，你可以省去额外的麻烦。

我选择lodash的三个主要原因是。。。

是的，JavaScript基元可以做什么和lodash可以做什么之间有一些重叠。至少对我自己来说，这不仅仅是map()的哪个实现更好，或者reduce()的哪个实现更好等等的问题。如果你所做的只是映射和减少，那么lodash就没有什么价值了。

另一方面，如果你构建一个中大型应用程序，你可能会对数据做更多的处理。这是一个洛达斯发光的地方。它以一种非常精细的形式给了我所需要的一切。粒度很重要，因为它意味着我可以选择和组合我需要的部分。我可以使用本机方法在自己身上做很多事情，但既然代码已经为我编写好了，为什么还要这样做呢？

洛达什表现不错。也许和浏览器基元一样好，或者在某些情况下更好。这没关系，性能的提高对于简单的比较来说是微不足道的。

巨大的性能胜利不是来自微观基准测试，而是在现实世界的实现中，那里有很多代码和数据。lodash的性能口号是针对常见情况进行优化。洛达什到处都这样做。

例如，在任何给定的函数中，首先检查更常见、性能更高的路径。慢速路径被推到函数的底部。他们可以慢慢来，因为他们不常见。这些检查在实际应用中具有巨大的累积效应。

当我操作集合时，我发现lodash的性能是一致的，因为它对所有涉及在集合上迭代的函数使用相同的迭代技术。所以我并不担心一个函数天生比另一个函数慢，因为它做事情的方式不同。差异是微小的，性能特征也是如此。

Lodash还考虑了JavaScript引擎的JIT，并采取措施确保其内部函数不会受到优化惩罚。

约翰·大卫·道尔顿对洛达什的表演进行了精彩的演讲。

由于所有公开的功能，我一直在寻找改进代码的方法。经常剥离函数调用，并用使用较少代码的不同策略替换它们。

我发现lodash，尤其是链式调用，可以很容易地改进现有代码。如果我必须自己编写所有这些实用程序，它不太可能像lodash版本那样优雅。

lodash API的粒度迫使我在做任何事情时都重新精简，这非常令人愉快。