lodash和下划线之间的区别

为什么有人更喜欢lodash.js或underscore.js实用工具库呢？

Lodash似乎是下划线的替代品，后者已经延长了。

我觉得这两者都很出色，但是我不太了解他们如何努力进行有教育的比较，我想了解更多的差异。

Answer 1

我创build了Lo-Dash来为数组，string，对象和arguments对象提供更一致的跨环境迭代支持。 它已经成为Underscore的超集，提供更一致的API行为，更多function （如AMD支持，深层克隆和深度合并），更全面的文档和unit testing（在Node，Ringo，Rhino，Narwhal，PhantomJS ，浏览器），大型数组/对象迭代的更好整体性能和优化，以及定制构build和模板预编译实用程序的更多灵活性。

由于Lo-Dash的更新频率比lodash underscore更频繁， 因此提供了一个lodash underscore构build，以确保与最新的lodash underscore稳定版本兼容。

有一次，我甚至被推到了Underscore，部分原因是Lo-Dash负责提出30多个问题; 在Underscore v1.4.x +中着陆bug修复，新function和性能提升。

此外，至less有3个Backbone样板默认包含Lo-Dash，而Lo-Dash现在在Backbone官方文档中提到。

查看Kit Cambridge的post， 向Lo-Dash说“Hello” ，以更深入地分析Lo-Dash和Underscore之间的差异。

脚注：

1. 下划线对数组，string，对象和arguments对象的支持不一致。 在较新的浏览器中，Underscore方法忽略数组中的空洞 ，“Objects”方法迭代arguments对象，string被视为类似数组，并且方法正确地迭代函数（忽略它们的“prototype”属性）和对象（迭代像“toString”和“valueOf”），而在旧版浏览器中则不会。 另外，像_.clone这样的_.clone方法可以在数组中保留空洞，而另一些像_.flatten则不会。

Answer 2

Lo-Dash的灵感来自于下划线，但现在是最好的解决scheme。 您可以进行自定义构build ，具有更高的性能 ，支持AMD并具有很多额外function 。 在jsperf上检查这个Lo-Dash vs Underscore的基准testing和..这个关于lo-dash的真棒post ：

使用集合时最有用的function之一是简写语法：

 var characters = [ { 'name': 'barney', 'age': 36, 'blocked': false }, { 'name': 'fred', 'age': 40, 'blocked': true } ]; // using "_.filter" callback shorthand _.filter(characters, { 'age': 36 }); // using underscore _.filter(characters, function(character) { return character.age === 36; } ); // → [{ 'name': 'barney', 'age': 36, 'blocked': false }] 

（取自lodash文档 ）

Answer 3

除了约翰的回答，还有关于lodash（我迄今为止也被认为是“我也是”）强调的读物，并且看到了性能testing，阅读源代码和博客post ，比下划线更优越的是：

1. 这不是速度，而是速度的一致性 （？）

   如果您查看下划线的源代码，您会在前几行中看到下划线落在许多函数的本地实现上。 虽然在理想的世界里，如果你看一下这些幻灯片中给出的一些性能链接，这将是一个更好的方法，但不难得出这样的结论，那就是“本地实现”的质量在很多浏览器上都有所不同，到浏览器。 Firefox在某些function上速度非常快，而在某些Chrome浏览器占据主导地位。 （我想可能会出现一些情况，IE也会占主导地位）。 我相信最好是select一个在浏览器上performance更一致的代码。

   请先阅读博客文章，而不是相信它，通过运行基准来评判自己。 我现在惊呆了，看到一个简单的 原生函数，比如Chrome中的Array.every ，就会比下划线快100-150％。

2. lodash中的额外function也非常有用。

3. 至于Xananax对于下划线代码的贡献高度评价：最好是有良好的竞争，不仅能保持创新，还能促使你保持自己（或你的图书馆）的良好状态。

下面是lodash之间的区别列表 ，它是下划线 – 构build是您的下划线项目的替代品。

Answer 4

如果像我一样，你期待着下划线和lodash之间的用法差异列表，那么有一个从下划线到lodash的迁移指南 。

以下是后代的现状：

• 下划线_.compose是Lodash _.flowRight
• 下划线_.contains是Lodash _.includes
• 下划线_.findWhere是Lodash _.find
• 下划线_.invoke是Lodash _.invokeMap
• 下划线_.mapObject是Lodash _.mapValues
• 下划线_.pluck是Lodash _.map
• 下划线_.where是Lodash _.filter
• _.any是Lodash _.some
• 下划线_.all是Lodash _.every
• 下划线_.each不允许通过返回false退出
• 下划线_.flatten在默认情况下很深，而Lodash很浅
• _.isFinite不与Number.isFinitealignment
  （例如， _.isFinite('1')在下划线中返回true ，而在Lodash中则为false ）
• 下划线_.matches速记不支持深度比较
  （例如_.filter(objects, { 'a': { 'b': 'c' } }) ）
• 下划线≥1.7＆Lodash已将其_.template语法更改为
  _.template(string, option)(data)
• Lodash _.uniq不接受像iteratee这样的iteratee函数。 使用Lodash _.uniqBy
• Lodash _.first和._last不接受像._last这样的n参数。 使用slice
• Lodash _.memoizecaching是像Map一样的对象
• Lodash支持隐式链接 ， 惰性链接和快捷方式融合
• Lodash将其重载的_.head ， _.last . _.rest ， _.last . _.rest ，＆ _.initial initial分割成
  _.take ， _.takeRight . _.take ， _.takeRight . _.drop ，＆ _.dropRight
  （即下划线中的_.take(array, 2)在Lodash中是_.take(array, 2) ）

Answer 5

这是2014年，还有一些太晚了。 我仍然认为我的观点是：

恕我直言，这个讨论已经被吹得不成比例。 引用上述博客文章 ：

大多数JavaScript实用程序库（如Underscore，Valentine和wu）都依赖于“本机优先的双重方法”。这种方法更喜欢本地实现，只有在不支持本地等价物的情况下才会回到香草JavaScript。 但jsPerf揭示了一个有趣的趋势：迭代数组或类似集合的最有效的方法是完全避免本地实现，而是select简单的循环。

就好像“简单循环”和“vanilla Javascript”比Array或Object方法实现更本地化。 Jeez …

拥有单一的事实来源当然是件好事，但事实并非如此。 即使你被告知，否则，没有香草上帝，亲爱的。 对不起。 唯一的假设是，我们都在编写JavaScript代码，目的是在所有主stream浏览器中都performance良好，知道它们都有不同的实现。 轻描淡写地处理这个问题是个婊子。 但是这是一个前提，不pipe你喜不喜欢。

也许你们都在研究大规模的项目，需要twitterish的performance，这样你才能真正看到现在每秒列表上的850,000（下划线）与2,500,000（lodash）迭代之间的区别！

我不是一个人。 我的意思是，我曾经在那些需要解决性能问题的项目上工作，但是这些项目从未被Underscore和Lo-Dash解决， 除非我认识到在实现和性能（我们现在正在谈论C ++）方面真正的差异，我们可以说一个循环遍历一个迭代（对象或数组，稀疏与否！），我宁可不打扰任何声称基于已经斟酌的基准平台的结果。

它只需要一个更新就可以说犀牛设置其数组方法实现在一个方式，没有一个单一的“中世纪循环方法performance更好，永远不会”和“什么”牧师可以争论他/她的方式围绕一个简单的事实，所有FF中的突然arrays方法比他/她的自以为是的脑袋快得多。 人，你不能欺骗你的运行环境！ 想想，当促进…

你的公用事业带

… 下次。

所以保持相关：

• 使用Underscore如果你在不牺牲原生的方便的情况下进入方便。
• 使用Lo-Dash是为了方便，像扩展的function目录（深层复制等），如果您迫切需要即时性能，最重要的是，只要原生API超越，就不要置身事外自以为是的工作。 哪一个即将发生。 期。
• 还有第三个解决scheme。 DIY！ 了解你的环境。 了解不一致。 阅读他们的（ 约翰大卫和杰里米的）密码。 如果不能解释为什么需要一致性/兼容性层，那么不要使用这个或那个，并增强您的工作stream程或提高应用程序的性能。 你的需求很可能满足于一个简单的polyfill，你完全可以自己写。 这两个图书馆都是普通的香草和一点糖。 他们都在争夺谁在服务最甜蜜的派 。 但相信我，最后都只是用水做饭。 没有香草上帝，所以不可能没有香草教皇，对吧？

select最适合您的需求的方法。 照常。 任何时候，我都希望在实际的实现方式上采用回头看看的运行时间欺骗，但即使这似乎是现在的品味问题。 坚持像http://developer.mozilla.com和http://caniuse.com这样的优质资源，你就会好起来的。;

Answer 6

有两个图书馆合并的趋势。 好主意我想！

https://github.com/jashkenas/underscore/issues/2182

Answer 7

不知道这是什么意思，但我来到这个问题，因为我正在寻找一个问题，我必须记住从下划线迁移到lodash时要记住的名单。

我真的很感激，如果有人发表了一篇文章，这些差异的完整列表。 让我从我学到的东西开始（也就是让我的代码在生产中爆炸的东西：/）：

• 下划线中的_.flatten默认是深层次的，你必须传递true作为第二个参数来使它变浅。 在lodash默认是浅的，并通过真正的第二个参数将使其深入！ 🙂
• 下划线中的_.last接受第二个参数，它告诉您需要多less个元素。 在lodash没有这样的select。 你可以用.slice来模拟这个
• _.first （同一问题）
• 下划线中的_.template可用于许多方面，其中之一就是提供模板string和数据并获取HTML （或者至less是前一段时间的工作原理）。 在lodash您将收到一个函数，然后您应该input数据。
• _(something).map(foo)以下划线工作，但是在lodash中，我不得不将其重写为_.map(something,foo) 。 也许这只是一个TypeScript组织

Answer 8

http://benmccormick.org/2014/11/12/underscore-vs-lodash/

比较两个由本麦考密克最新的文章：

1. Lo-Dash的API是Underscore的超集。

2. 在引擎盖下[Lo-Dash]已被彻底改写。

3. Lo-Dash绝对不会比Underscore慢。

4. Lo-Dash添加了什么？

   • 可用性改进
   • 额外的function
   • 性能增益
   • 简化链接的语法
   • 自定义构build只使用你所需要的
   • 语义版本和100％的代码覆盖率

Answer 9

我同意这里所说的大部分内容，但是我只想指出一个赞成underscore.js的论点：图书馆的规模。

特别是如果你正在开发一个打算主要在移动设备上使用的应用程序或网站，那么产生的包的大小以及对引导或下载时间的影响可能起着重要的作用。

为了比较，这些尺寸是我在运行离子服务器后用source-map-explorer注意到的那些尺寸：

 lodash: 523kB underscore.js: 51.6kb 

Answer 10

我只是发现一个最终对我很重要的差异。 lodash的_.extend()的非下划线兼容版本不会复制类级定义的属性或方法。

我在CoffeeScript中创build了一个Jasminetesting，演示了这一点：

https://gist.github.com/softcraft-development/1c3964402b099893bd61

幸运的是， lodash.underscore.js保留了lodash.underscore.js复制所有内容的行为，这对我的情况来说是期望的行为。

Answer 11

lodash得到了_.mapValues() ，它和underescore的_.mapObject()是一样的。

Answer 12

大部分下划线是lodash的子集。 有时候，像现在的下划线会有很酷的小函数lodash没有像mapObject那样的。 这节省了我很多时间在我的项目的发展。