为什么有人更喜欢Lodash或Undercore.js实用程序库而不是另一个?

Lodash似乎是下划线的替代品,后者已经存在了更长的时间。

我认为两者都很出色,但我对它们的工作原理了解不足,无法进行有意义的比较,我想了解更多的差异。


当前回答

本·麦考密克(Ben McCormick)的《Undercore vs Lo Dash》(Undercore vs Lo Dash)是最新一篇将两者进行比较的文章:

Lodash的API是Undercore.js的超集。

在幕后,洛达什被彻底改写了。

Lodash绝对不会比Undercore.js慢。

Lodash补充了什么?

可用性改进额外功能性能提升链接的速记语法自定义生成以仅使用所需内容语义版本控制和100%代码覆盖率

其他回答

2014年,我仍然认为我的观点是正确的:

天啊,这场讨论有点不成比例。引用上述博文:

大多数JavaScript实用程序库,如Undercore、Valentine和吴,依靠“本土第一双重方法”。这种方法更倾向于本地实现,只有在不支持本机等效项。但jsPerf透露了一个有趣的趋势:迭代数组或类似数组的最有效方法集合是为了完全避免本机实现而不是简单的循环。

似乎“简单循环”和“香草Javascript”比Array或Object方法实现更原生。天啊。。。

有一个单一的真相来源当然很好,但事实并非如此。即使有人告诉你,亲爱的,也没有香草神。我很抱歉。唯一真正成立的假设是,我们都在编写JavaScript代码,目的是在所有主要浏览器中都能很好地运行,因为我们知道所有浏览器都有不同的实现方式。委婉地说,这是一个需要处理的婊子。但这是前提,无论你是否喜欢。

也许你们所有人都在从事需要Twitter性能的大型项目,这样你就可以在每秒列表中看到850000次(Undercore.js)与2500000次(Lodash)迭代之间的差异了!

我不是。我的意思是,我从事的项目必须解决性能问题,但Undercore.js和Lodash都没有解决或导致这些问题。除非我掌握了实现和性能上的真正差异(我们现在说的是C++),比方说,在可迭代(对象或数组,稀疏或不稀疏!)上的循环,否则我不会因为任何基于已经有观点的基准平台结果的声明而烦恼。

它只需要对Rhino进行一次更新,就可以让它的Array方法实现以一种“中世纪循环方法的性能更好、更持久”的方式启动,牧师无法反驳一个简单的事实,即Firefox中突然出现的数组方法比他/她固执己见的头脑快得多。伙计,你不能通过欺骗你的运行时环境来欺骗你的环境!在推广时要考虑到这一点。。。

你的实用皮带

下一次

因此,为了保持相关性:

如果您想在不牺牲本地语言的情况下方便使用Undercore.js。如果你想方便使用,并且喜欢它的扩展功能目录(深度复制等),如果你迫切需要即时性能,最重要的是,不要介意在本地API的解决方案超越了固执己见的解决方案后,立即选择替代方案。这很快就会发生。时期甚至还有第三种解决方案。自己动手做!了解您的环境。了解不一致性。阅读他们(约翰·戴维和杰里米)的代码。不要在无法解释为什么真正需要一致性/兼容性层并增强您的工作流程或提高应用程序性能的情况下使用这个或那个。您的需求很可能通过一个简单的polyfill得到满足,您完全可以自己编写。这两个库都是纯香草和少许糖。他们都在为谁做最甜的馅饼而争吵。但相信我,最终两人都只是用水做饭。没有香草神,所以不可能没有香草教皇,对吧?

选择最适合您需求的方法。和往常一样。我更喜欢在实际实现上的倒退,而不是在任何时候固执己见的运行时欺骗,但即使是现在,这似乎也是一个品味问题。坚持优质资源,如http://developer.mozilla.com和http://caniuse.com你会没事的。

我不确定OP是不是这个意思,但我遇到了这个问题,因为我在搜索从Undercore.js迁移到Lodash时必须记住的问题列表。

如果有人发表一篇文章,列出这些差异的完整列表,我将非常感激。让我从我用艰难的方式学到的东西开始(也就是说,那些让我的代码在生产中爆炸的东西:/):

_默认情况下,Undercore.js中的.sflat为deep,必须将true作为第二个参数传递,使其变浅。在Lodash中,默认情况下它是浅的,将true作为第二个参数传递将使其变深!:)_Underscore.js中的.last接受第二个参数,该参数告诉您需要多少元素。在Lodash,没有这样的选择。您可以使用.sslice来模拟这一点_.第一期(同一期)_可以以多种方式使用Undercore.js中的.template,其中之一是提供模板字符串和数据并获取HTML(或者至少这是一段时间前的工作方式)。在Lodash中,您会收到一个函数,然后您应该向该函数提供数据。_(something).map(foo)在Undercore.js中工作,但在Lodash中,我不得不将其重写为_.map(somethink,foo)。也许这只是TypeScript问题。

Undercore.js大部分是Lodash的子集。

有时,就像现在一样,Undercore.js会有Lodash没有的一些很酷的小功能,比如mapObject。这一次为我的项目开发节省了大量时间。

如果像我一样,您期望Undercore.js和Lodash之间的使用差异列表,那么有一个从Undercore.jss迁移到Lodash的指南。

以下是留给子孙后代的现状:

下面的任何一个都是LodashUndercore _.all是Lodash _.every下划线_.compose是Lodash _.flowRightUndercore _.contains是Lodash _.includesundercore_.each不允许通过返回false退出Undercore_.findLodash在哪里_.find默认情况下,Undercore _.flatten为深,而Lodash为浅Undercore_.groupBy支持传递参数(value、index、originalArray)的iterate,而在Lodash中,_.groupBy的iteratee只传递了一个参数:(value)。未定义第三个参数的Undercore.js_.indexOf是Lodash _.indexOf具有第三个参数true的Undercore.js_.indexOf是Lodash _.sortedIndexOfUndercore_.indexBy是Lodash _.keyBy调用的核心是Lodash_.invokeMapUndercore_.mapObject是Lodash _.mapValuesUndercore_.max组合Lodash _.max和_.maxByUndercore_.min组合Lodash _.min和_.minByUndercore_.sample组合Lodash _.sample&_.sampleSizeUndercore_.object组合了Lodash _.fromPairs和_.zip对象谓词下面的省略是Lodash省略下划线_.pairs是Lodash _.to pairs谓词下面的pickBy是Lodash_.pickBy下面是Lodash地图Undercore_.sortedIndex组合了Lodash _.sorted索引和_.sorttedIndexOf迭代者的下划线_.uniq是Lodash _.uniqByUndercore _.哪里是Lodash _.filterUndercore_.isFinite与Number.isFinite不对齐(例如_.isFinite('1')在Undercore.js中返回true,但在Lodash中返回false)Undercore_.matches速记不支持深度比较(例如,_.filter(对象,{“a”:{“b”:“c”}}))下划线≥1.7&Lodash _.template语法为_.templ(字符串,选项)(数据)内存缓存是类似于地图的对象Lodash不支持许多支持_.bind的方法的上下文参数Lodash支持隐式链接、惰性链接和快捷方式融合Lodash将其过载的_头、_尾、_尾和_首字母拆分为_take,take对,drop,和drop对(即Undercore.js中的_.head(array,2)是Lodash中的_.take(array))

我同意这里所说的大部分内容,但我只想指出一个支持Undercore.js的论点:库的大小。

特别是如果您正在开发一个主要用于移动设备的应用程序或网站,那么生成的捆绑包的大小以及对启动或下载时间的影响可能会起到重要作用。

为了进行比较,这些大小是我在运行Ionic服务后在源地图浏览器中注意到的大小:

Lodash: 523 kB
Underscore.js: 51.6 kB

可以使用BundlePhobia检查Lodash和Undercore.js的当前大小。