为什么有人会比其他人更喜欢lodash.js或underscore.js实用程序库?
Lodash似乎是下划线的替代品,下划线的使用时间更长。
我认为两者都很出色,但是我对它们的工作方式还不甚了解,无法进行有根据的比较,我想进一步了解它们之间的差异。
为什么有人会比其他人更喜欢lodash.js或underscore.js实用程序库?
Lodash似乎是下划线的替代品,下划线的使用时间更长。
我认为两者都很出色,但是我对它们的工作方式还不甚了解,无法进行有根据的比较,我想进一步了解它们之间的差异。
我只是发现一个差异,最终对我来说很重要。lodash的的非下划线兼容的版本_.extend()
并没有拷贝过来的类级定义的属性或方法。
我已经在CoffeeScript中创建了一个Jasmine测试,以证明这一点:
https://gist.github.com/softcraft-development/1c3964402b099893bd61
幸运的是,lodash.underscore.js
保留了Underscore复制所有内容的行为,这对我来说是理想的行为。
lodash得到的_.mapValues()
内容与underescore的相同_.mapObject()
。
不知道这是否是OP的意思,但是我遇到了这个问题,因为我在搜索从下划线迁移到lodash时必须牢记的问题列表。
如果有人发布一篇包含此类差异的完整列表的文章,我将不胜感激。让我从我艰难学习的东西开始(也就是说,使我的代码在生产中爆炸的东西:/):
_.flatten
下划线默认是深的,您必须将true作为第二个参数传递以使其变浅。在lodash中,默认情况下它是浅的,而将true作为第二个参数传递将使其变深!:)_.last
下划线中的ins接受第二个参数,它告诉您要多少个元素。在lodash
没有这样的选项。您可以使用.slice
_.first
(同一期)_.template
下划线中的可以通过多种方式使用,其中之一是提供模板字符串和数据并HTML
取回(或者至少是一段时间前的方式)。在lodash
其中,您将收到一个函数,然后应将其提供给数据。_(something).map(foo)
在下划线下工作,但在lodash中我不得不将其重写为_.map(something,foo)
。也许那只是一个TypeScript
问题http://benmccormick.org/2014/11/12/underscore-vs-lodash/
Ben McCormick的最新文章将两者进行了比较:
Lo-Dash的API是Underscore的超集。
引擎盖下的[Lo-Dash]已被完全重写。
Lo-Dash绝对不比Underscore慢。
Lo-Dash添加了什么?
- 可用性改进
- 额外功能
- 绩效提升
- 链接的简写语法
- 自定义构建仅使用您需要的内容
- 语义版本控制和100%的代码覆盖率
我同意这里所说的大多数内容,但我只想指出一个支持underscore.js的论点:库的大小。
特别是在您开发打算主要在移动设备上使用的应用程序或网站的情况下,所得捆绑包的大小以及对启动或下载时间的影响可能会发挥重要作用。
为了进行比较,这些大小是我运行离子服务后在source-map-explorer中注意到的大小:
lodash: 523kB
underscore.js: 51.6kb
2020年2月编辑:
人们可以使用BundlePhobia检查的当前大小罗短跑和下划线
除了John的回答之外,还阅读了lodash(到目前为止,我将其视为下划线的“我也很想”),并查看了性能测试,阅读了源代码和博客文章,这是使lodash的几点。这些要比下划线要好得多:
这不关乎速度,而是关乎速度的一致性(?)
如果查看下划线的源代码,您会在前几行中看到下划线是许多功能的本机实现的后备。尽管在理想情况下,这本来是一种更好的方法,但是如果您看一下这些幻灯片中提供的一些性能链接,则不难得出这样的结论,即这些“本机实现”的质量在很大程度上取决于浏览器,浏览器。Firefox在某些功能上非常快速,在某些Chrome中占主导地位。(我想在某些情况下IE也将占主导地位)。我认为最好是使用跨浏览器性能更一致的代码。
一定要早点阅读该博客文章,而不是为了它而相信它,而是通过运行基准来自己判断。我现在被惊呆了,看到即使在简单的原生功能(例如
Array.every
Chrome)中,lodash的执行速度也比下划线快100-150%!
lodash 的附加功能也非常有用。
大多数情况下,下划线是lodash的子集。有时,像现在的下划线一样,会有一些很棒的小功能,而lodash却不像mapObject。这为我节省了很多时间来开发项目。