关于underline.js: lodash and underscore 之间的区别

Differences between lodash and underscore

为什么有人喜欢lodash.js或underline.js实用程序库而不是另一个？

罗达什似乎是一个替代下划线的下降，后者已经存在了更长的时间。

我认为两者都很出色，但我不太了解它们是如何工作的，无法进行有教育意义的比较，我想了解更多的差异。

我创建了lo dash来为数组、字符串、对象和arguments对象提供更一致的跨环境迭代支持1。它已经成为下划线的超集，提供了更一致的API行为、更多的功能(如AMD支持、Deep Clone和Deep Merge)、更全面的文档和单元测试(在节点、Ringo、Rhino、Narwhal、Phantomjs和浏览器中运行的测试)、更好的总体性能和大型数组/对象迭代的优化，以及更灵活的定制构建和模板预编译实用程序。

由于lo dash的更新频率高于下划线，因此提供了lodash underscore构建，以确保与下划线的最新稳定版本兼容。

在某一点上，我甚至可以通过推送访问下划线，部分原因是LoDash负责引发30多个问题：登录错误修复、新功能以及下划线v1.4.x+的性能提升。

此外，至少有3个主干样板文件默认包括lo dash，而lo dash现在已在主干文件中提到。

查看KitCambridge的帖子，从"你好"到"低破折号"，深入分析"低破折号"和下划线之间的区别。

脚注：

下划线对数组、字符串、对象和arguments对象的支持不一致。在较新的浏览器中，下划线方法忽略数组中的孔，"对象"方法迭代arguments对象，字符串被视为类似数组，方法正确迭代函数(忽略其"原型"属性)和对象(迭代隐藏的属性，如"toString"和"valueof")，而在较旧的浏览器中，它们不会。此外，强调像_.clone这样的方法保留了数组中的孔，而像_.flatten这样的方法则没有。

相关讨论

谢谢你的回答，约翰·大卫，非常感谢你的想法。你认为合理地说罗达什实际上总是比强调更可取吗？(更好的问题是：你能想到有谁会反对这个断言吗？)多谢。
@布莱恩-在开发lo-dash时，我继续问一个问题："在lo-dash中，与下划线相比，有人能指出什么是负面的？"然后对他们讲话。这就是为什么我增加了文档，添加了自定义构建，并使源代码更易于阅读的原因。
我很想发布一些基准，但这可能会变得单调乏味。我已经证明，我运行的每个基准测试都比下划线更快(很多情况下更快)。
为什么主干样板文件包含到lodash和下划线的路径？在my require.config(路径：'下划线'："_lib/lodash/v1.0.0-rc3/lodash-min"
@Shanimal:主干需要下划线。样板文件不使用下划线，而是希望使用lodash作为替换，因此它设置了指向lodash位置的"下划线"路径。
我喜欢lo dash，而且我正在使用它，所以请不要认为我在抨击它，但是为什么不贡献下划线而不是创建一个新的库呢？
在我的火狐19上，在运行jspef.com/lo dash-underline时，mint-underline似乎比lo-dash更快。但在谷歌Chrome26上，情况正好相反。如我所见，它依赖于浏览器。
@xananax-检查comments线程：github.com/jashkenas/underline/commit/&hellip；-这可能会回答该问题。
@罗伯特格兰特看起来有点感情用事：github.com/jashkenas/underline/commit/&hellip；在运行npm update时，我看到了更多的lo-dash依赖性。我得看看这个。
此外，我还发现，对于lodash和underline，_.union函数的不同之处在于underscore.union([], 3) === [3]和lodash.union([], 3) === []。
@Kumarharsh请参阅github.com/jashkenas/underline/pull/1317下一版本的underline应与lodash在该问题上保持一致。
是否有任何努力将lodash合并回下划线？
Lo Dash 3.0将支持Lazy Evaluation，而下划线不支持Lazy Evaluation。请阅读更多信息：filimanjaro.com/blog/2014/introducing-lazy-evaluation
@街灯：现在有了(还是相反？)
欠灰计划正在进行中！
为什么不直接修补下划线xd？
哦，政治。我只想要一个图书馆。
看看本文引用的"hello"to lo dash"native first dual approach"。这种方法更倾向于本机实现，只有在不支持本机等价物的情况下才返回到普通的javascript。"我很困惑，native和vanilla javascript有什么区别？
@由浏览器(本机)提供的claymorton函数与必须由JS运行时(非本机)运行的函数。
我听说ramda.js更适合纯函数编程？
@阿列克谢米尔洛达什覆盖了洛达什FP。
在我看来，有一件事是下划线放在了Lodash前面，尽管每个人都看到了截然相反的情况：Underline的登录页面上都有文档，其中包含搜索字段，而对于Lodash，您还需要另外一个步骤-单击登录页面上的"文档"链接，最终到达您想去的地方。这是一件微不足道的事情，但当你每天都这样做的时候，时间上的差别就很大了。

低破折号的灵感来源于下划线，但现在是更好的解决方案。你可以做你的定制版本，有更高的性能，支持AMD和有伟大的额外功能。检查此长划线与JSPERF和..上的下划线基准。这篇关于Lo Dash的精彩文章：

使用集合时最有用的功能之一是速记语法：

1
2
3
4
5
6
7
8
9
10
11
12

(摘自洛达什文件)

相关讨论

如果像我一样，您希望看到下划线和lodash之间的用法差异列表，那么这里有一个从下划线迁移到lodash的指南。

以下是子孙后代的现状：

Underscore _.any is Lodash _.some

Underscore _.all is Lodash _.every

Underscore _.compose is Lodash _.flowRight

Underscore _.contains is Lodash _.includes

Underscore _.each doesn’t allow exiting by returning false

Underscore _.findWhere is Lodash _.find

Underscore _.flatten is deep by default while Lodash is shallow

Underscore _.groupBy supports an iteratee that is passed the parameters (value, index, originalArray),
while in Lodash, the iteratee for _.groupBy is only passed a single parameter: (value).

Underscore _.indexOf with 3rd parameter undefined is Lodash _.indexOf

Underscore _.indexOf with 3rd parameter true is Lodash _.sortedIndexOf

Underscore _.indexBy is Lodash _.keyBy

Underscore _.invoke is Lodash _.invokeMap

Underscore _.mapObject is Lodash _.mapValues

Underscore _.max combines Lodash _.max & _.maxBy

Underscore _.min combines Lodash _.min & _.minBy

Underscore _.sample combines Lodash _.sample & _.sampleSize

Underscore _.object combines Lodash _.fromPairs and _.zipObject

Underscore _.omit by a predicate is Lodash _.omitBy

Underscore _.pairs is Lodash _.toPairs

Underscore _.pick by a predicate is Lodash _.pickBy

Underscore _.pluck is Lodash _.map

Underscore _.sortedIndex combines Lodash _.sortedIndex & _.sortedIndexOf

Underscore _.uniq by an iteratee is Lodash _.uniqBy

Underscore _.where is Lodash _.filter

Underscore _.isFinite doesn’t align with Number.isFinite
(e.g. _.isFinite('1') returns true in Underscore but false in Lodash)

Underscore _.matches shorthand doesn’t support deep comparisons
(e.g. _.filter(objects, { 'a': { 'b': 'c' } }))

Underscore ≥ 1.7 & Lodash _.template syntax is_.template(string, option)(data)

Lodash _.memoize caches are Map like objects

Lodash doesn’t support a context argument for many methods in favor of _.bind

Lodash supports implicit chaining, lazy chaining, & shortcut fusion

Lodash split its overloaded _.head, _.last, _.rest, & _.initial out into
_.take, _.takeRight, _.drop, & _.dropRight
(i.e. _.head(array, 2) in Underscore is _.take(array, 2) in Lodash)

相关讨论

除了约翰的回答，以及阅读关于lodash的文章(我以前认为这是一个"我也"来强调)，以及看到性能测试、阅读源代码和博客文章，使lodash远远优于强调的几点是：

这不是关于速度，而是关于速度的一致性(？)

If you look into underscore's source-code, you'll see in the first few lines that underscore falls-back on the native implementations of many functions. Although in an ideal world, this would have been a better approach, if you look at some of the perf links given in these slides, it is not hard to draw the conclusion that the quality of those 'native implementations' vary a lot browser-to-browser. Firefox is damn fast in some of the functions, and in some Chrome dominates. (I imagine there would be some scenarios where IE would dominate too). I believe that it's better to prefer a code whose performance is more consistent across browsers.

Do read the blog post earlier, and instead of believing it for its sake, judge for yourself by running the benchmarks. I am stunned right now, seeing a lodash performing 100-150% faster than underscore in even simple, native functions such as Array.every in Chrome!

罗达什的额外费用也很有用。

至于xananax的高度乐观的评论，它建议对强调的准则作出贡献：拥有良好的竞争总是更好的，它不仅能保持创新，而且能促使你保持良好的状态(或你的图书馆)。

这里列出了lodash之间的区别，它的下划线构建是对下划线项目的替换。

相关讨论

在哪种情况下，"速度一致性"是一个值？比如说，我有一个方法在FF和IE中的速度为100%，而本机实现在IE中的速度为80%，在FF中的速度为120%(或者反过来)。那么我会说在FF中使用本机实现和在IE中使用本机实现是很好的。我无法想象任何情况，我会说：让我们放慢FF的速度仅仅是因为它的速度与在IE中的速度相同。代码的大小和可维护性，或者所有浏览器的平均速度都会变慢，但是速度的一致性呢？
我的意思是，"一直保持更快的速度"
一辆20公里/小时一天的车没什么用。)
尺寸有什么不同？假设您使用与下划线功能完全相同的lodash创建了一个自定义构建？他们之间有很大的区别吗？我想重新实现会增加站点的权重。
下划线的占地面积较小，因为它主要覆盖本机函数。
我倾向于退回到浏览器的本机实现，因为在大多数情况下，它具有可接受的性能，并且可以随着浏览器更新而改进，而无需担心使库保持最新。
@或者你可能想多读一点。在某些情况下，本机实现没有可接受的性能。只是说…
@奥拉德：不管怎样，你都可以，即使我倾向于…但接下来是支持IE8的案例——在某些情况下，你真的无能为力。无论如何，不要盲目地丢弃库，而是看看源代码：在某些情况下，lodash/underlinelibs只是稍微包装了本机实现。
@库马尔哈什也许我说得不好。我的意思是我倾向于使用一个内部使用本机函数(如果可用)的库，而不是总是倾向于自己的实现。
@库马尔·哈什，我们说的是一辆时速不能超过60公里的跑车。不管怎样，你不会知道城市驾驶的区别。如果你大部分时间都在城里开车，你就不需要更好的车了。城市驾驶是一般项目中的大部分代码。
好吧，跟车比较一下就够了：)…底线是作为一个开发人员，你可以使用你想要的任何东西。当您的环境是nodejs或者您的构建链中有webpack时，lodash更好，不需要问任何问题。对于浏览器来说，lodash也更好(它提供的功能更有用)。如果出于某种原因您真的想使用下划线，那么lodash有一个核心构建，实际上它比下划线小，尽管我不知道它的下划线构建的大小。
另外，在Webpack中，对于现在的大多数函数，我只使用本机实现。[].map等只是babel在编译时确定的，如果我选择面向ES5浏览器，那么大多数时候我会发现自己使用lodash来处理ES6中没有的特性，或者不太容易编写，比如_.sortBy等。

现在是2014年，晚了几年。但我认为我的观点是：

我觉得这个讨论有点不合时宜。引用上述博客文章：

Most JavaScript utility libraries, such as Underscore, Valentine, and
wu, rely on the"native-first dual approach." This approach prefers
native implementations, falling back to vanilla JavaScript only if the
native equivalent is not supported. But jsPerf revealed an interesting
trend: the most efficient way to iterate over an array or array-like
collection is to avoid the native implementations entirely, opting for
simple loops instead.

就好像"简单循环"和"普通javascript"比数组或对象方法实现更为原生。哎呀…

有一个单一的真理来源当然很好，但是没有。即使你被告知没有，也没有香草神，亲爱的。我很抱歉。唯一的假设是，我们都在编写旨在在所有主要浏览器中表现良好的JavaScript代码，因为我们知道所有浏览器都具有相同事物的不同实现。委婉地说，这是一个需要应付的婊子。但这是前提，不管你喜欢与否。

也许你们都在研究需要Twitter性能的大型项目，这样你们就可以真正看到每秒列表中850000次(下划线)和2500000次(lodash)迭代之间的差异了！

我一个人不是。我的意思是，我工作的项目必须解决性能问题，但它们从来没有得到解决，也不是由下划线或长划线造成的。除非我了解在执行和性能上的真正差异(我们现在谈论C++)，让我们说一个循环在一个迭代(对象或数组，稀疏或不！)上。我宁愿不为任何基于基准平台结果的声明而烦恼，因为基准平台已经是固执己见的。

它只需要对Lets-Say Rhino进行一次单一的更新，就可以让它的数组方法实现以一种没有任何一个"中世纪的循环方法能够永远更好地执行，什么都不能"的方式启动，牧师可以围绕着这样一个简单的事实争论，即FF中所有突然出现的数组方法都比他/她的自以为是的大脑快得多。伙计，你不能通过欺骗你的运行环境来欺骗你的运行环境！提升的时候考虑一下…

your utility belt

…下一次。

因此，为了保持相关性：

如果在不牺牲本地ish的情况下方便使用，请使用下划线。
如果您很方便并且喜欢它的扩展功能目录(深度复制等)，并且如果您迫切需要即时性能，最重要的是，不要介意在本机API的高瞻远瞩的工作成果出现时就选择一种替代方案。这很快就会发生。时期。
甚至还有第三种解决方案。自己动手做！了解你的环境。了解不一致。阅读他们的(约翰·大卫和杰里米的)密码。如果不能解释为什么真正需要一致性/兼容性层，并增强您的工作流程或提高应用程序的性能，请不要使用这个或那个。很可能你的需求是满足于一个简单的polyfill，你完全能够写自己。两个图书馆都是纯香草加一点糖。他们都在为谁提供最甜的馅饼而争吵。但相信我，最终两人都只是用水做饭。没有香草神，所以就没有香草教皇，对吧？

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

相关讨论

谢谢你寄卢卡斯。内置组件可以进一步优化吗？我收集到，它们受到标准的约束，这些标准阻止它们进行与库类似的优化，但我不知道现在的细节，也不知道这是否是真的。
例如，"通过对99%的用例进行优化，fast.js方法可以比其本地等效方法快5倍。"–github.com/codemix/fast.js
嗨，布莱恩，如果这是误导我的话，我很抱歉，我不是说那些图书馆的速度比它们的本地版本快得多。如果您现在迫切需要性能，那么使用像lodash或fast.js这样的工具包可能会更好，因为它们提供了更快的标准方法实现。但是，如果您选择使用一个不依赖于本机方法的库，那么您可能会错过任何内置的未来性能优化。浏览器最终会进化。
谢谢卢卡斯。我猜，如果浏览器最终偏离或发展了JavaScript标准，那么它们可能达到(并且超过，如您所说)库的性能。我怀疑这还远着呢，但谁知道呢。人们可以希望。)欢呼
jspef.com/native-vs-array-js-vs-underline/37。至少在这种情况下，循环或array.map都能赢得比赛。
仅作记录：javascript/ecma标准或规范仅在功能签名等方面具有描述性，在实施方面不施加任何规则或指南。"标准"与性能无关。
浏览器"制造商"很难让他们的浏览器符合标准，性能要差得多。在本机实现中，大多数性能提升都是硬件速度更快的结果。"本机实现将迎头赶上"的借口已经存在多年了。年=互联网上的永恒。如果本机实现赶上了，库将被更新以使用它们。这是关于开源的很酷的事情。如果一个应用程序开发人员没有更新到最新的库，他们的应用程序不会突然减速，只是不会加速。
安德鲁，谢谢你分享你的想法。老实说，浏览器制造商是否关心性能超出了我的知识范围。但我知道，通过发明"效用带"，似乎根本不关心标准函数签名约定，并没有助于解决标准遵从性问题。有一半的JS开发人员可能会背诵每个人和每个人的签名(包括callback=_.identity 公约，事实上，该公约鼓励人们甚至不提供回拨)，即使是在几个投手之后……
…但是如果你问他们关于Array.from的事情，他们可能甚至不知道该怎么做。JS"效用带"的人们似乎过于关注促进他们的工作环境，以至于他们往往忘记这样做实际上是在稀释标准化过程。不需要特性就不会给浏览器"制造商"带来压力。有趣的事实：4个主要浏览器中有2个基于开源项目(1，2)。
关于洛达什的迪普复制品的好观点。我一直希望在从事基于下划线的项目时能做到这一点。

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

特别是在您开发的应用程序或网站打算主要在移动设备上使用的情况下，产生的捆绑包的大小以及对引导或下载时间的影响可能具有重要作用。

为了进行比较，这些大小是我在运行离子服务器之后通过源地图浏览器注意到的大小：

1 2	lodash: 523kB underscore.js: 51.6kb

相关讨论

不确定这是否是OP的意思，但我回答了这个问题，因为我在搜索从下划线迁移到lodash时必须记住的问题列表。

如果有人发表了一篇文章列出了这些差异，我会非常感激。让我从我学到的困难的东西开始(也就是说，使我的代码在生产中爆炸的东西：/)：

下划线中的_.flatten在默认情况下是深的，您必须将true作为第二个参数传递，使其变浅。在Lodash中，默认情况下它是浅的，并且作为第二个参数传递true将使它变深！：)
下划线中的_.last接受第二个参数，该参数指示需要多少元素。在lodash中没有这样的选择。你可以用.slice来模仿这个。
_.first(同一版本)
下划线中的_.template可用于多种方式，其中一种方式是提供模板字符串和数据，并使HTML返回(或者至少在一段时间前是这样工作的)。在lodash中，您将收到一个函数，然后应该用该函数来提供数据。
_(something).map(foo)的工作是用下划线，但在lodash，我不得不重写为_.map(something,foo)。也许这只是一个江户问题

相关讨论

http://benmcormick.org/2014/11/12/underline-vs-lodash/

本·麦考密克最新的一篇文章比较了这两者：

Lo-Dash's API is a superset of Underscore's.

Under the hood [Lo-Dash] has been completely rewritten.

Lo-Dash is definitely not slower than Underscore.

What has Lo-Dash added?

Usability Improvements

Extra Functionality

Performance Gains

Shorthand syntaxes for chaining

Custom Builds to only use what you need

Semantic versioning and 100% code coverage

我只是发现了一个对我来说很重要的区别。Lodash的_.extend()的非下划线兼容版本不会复制类级定义的属性或方法。

我在CoffeeDescript中创建了一个茉莉花测试，演示了这一点：

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

幸运的是，lodash.underscore.js保留了强调复制所有东西的行为，在我看来，这是理想的行为。

罗达什得到了与underescore的_.mapObject()相同的_.mapValues()。

在大多数情况下，下划线是lodash的子集。有时，像现在这样，下划线会有一些很酷的小功能，lodash没有like mapobject。这一个在我的项目开发中节省了我很多时间。

相关讨论

它们很相似，由洛达什接管…

它们都是一个实用程序库，在javascript中采用了实用程序的世界…

似乎罗达什现在更新得更频繁了，所以更多的应用在最新的项目中…

另外，洛达什似乎是更轻的几Kbs…

两者都有很好的API和Doc，但我认为Lodash一个更好…

以下是获取数组第一个值的每个文档的屏幕截图…

强调：

underscore

拉达什： lodash

因为事情可能会得到及时更新，只要检查他们的网站也…

落叶

强调