当直接的 JS 函数可以完成这项工作时，我倾向于发现列出的库被更频繁地使用。我相信加载额外的库总是会增加更多的加载时间，所以我很好奇为什么不经常使用原始 JS 函数。
语言中的纯 JS 函数与后编写的辅助函数相比有什么速度优势吗？
难道预制库的好处不会因为额外的库加载时间而丧失吗？
【问题讨论】：
标签： javascript dictionary underscore.js reduce lodash
通常使用框架而不是原始 JS 是兼容性。浏览器之间，不同版本的浏览器之间的Javascript存在差异，并且一些实现不完整。下划线之类的工具有助于解决兼容性问题，在您的代码和原始 JS 之间提供一个公共层。
如果您可以消除使用不同浏览器的可能性，那么当然可以继续使用 Raw JS，但从长远来看，您可以为自己省去额外的麻烦。
【讨论】：
var nativeIsArray = Array.isArray, nativeKeys = Object.keys, nativeCreate = Object.create; 稍后用于确定函数是否已经存在然后使用它，否则它定义了一个新函数。还有其他例子，但这些是最直接的例子..
我转向 lodash 的三个主要原因...
是的，JavaScript 原语可以做什么和 lodash 可以做什么之间有一些重叠。至少对我自己而言，这不仅仅是map() 的哪个实现更好，或者reduce() 的哪个实现更好等等问题。如果你所做的只是映射和缩减，那么 lodash 就没有什么价值了。
另一方面，如果您构建的是中型到大型应用程序，那么您可能需要对数据做更多的事情。这是 lodash 大放异彩的地方。它以非常精细的形式为我提供了我需要的一切。粒度很重要，因为这意味着我可以选择和组合我需要的部分。我可以使用本机方法在自己身上做很多事情，但是当代码已经为我编写好了，为什么还要这样做呢？
Lodash 表现良好。也许和浏览器原语一样好，或者在某些情况下更好。没关系，性能提升对于简单的比较可以忽略不计。
巨大的性能优势不是来自微基准测试，而是来自实际实现，其中有大量代码和大量数据。 lodash 的性能准则是针对常见情况进行优化。 Lodash 无处不在。
例如，在任何给定函数中首先检查更常见、更高效的路径。慢速路径被推到函数的底部。他们可以承受缓慢，因为他们不常见。这些检查在实际应用中具有巨大的累积效应。
当我对集合进行操作时，我发现 lodash 的性能是一致的，因为它对涉及迭代集合的所有函数使用相同的迭代技术。所以我不担心一个函数本质上比另一个函数慢，因为它做的事情不同。差异很小，性能特征也是如此。
Lodash 还考虑 JavaScript 引擎的 JIT，并采取措施确保其内部函数不会招致优化损失。
John-David Dalton 在talk 的 lodash 表现上表现出色。
由于所有公开的功能，我一直在寻找改进代码的方法。经常删除函数调用，并用使用更少代码的不同策略替换它们。
我发现 lodash，尤其是链式调用，可以很容易地改进现有代码。如果我必须自己编写所有这些实用程序，它可能不会像 lodash 版本那样优雅。
lodash API 的粒度迫使我重新思考我正在做的每一件事，就像我正在做的那样，这非常令人愉快。
【讨论】：