lodash和下划线之间的差异[关闭]

本文翻译自：Differences between lodash and underscore [closed]

Why would someone prefer either the lodash.js or underscore.js utility library over the other? 为什么有人更喜欢lodash.js或underscore.js实用程序库而不是另一个？

Lodash seems to be a drop-in replacement for underscore, the latter having been around longer. Lodash似乎是下划线的替代品，后者已经存在了更长时间。

I think both are brilliant, but I do not know enough about how they work to make an educated comparison, and I would like to know more about the differences. 我认为两者都很精彩，但我对他们如何努力进行有根据的比较并不了解，我想更多地了解这些差异。

---

#1楼

参考：https://stackoom.com/question/vrJC/lodash和下划线之间的差异-关闭

---

#2楼

Lo-Dash is inspired by underscore, but nowadays is superior solution. Lo-Dash的灵感来自下划线，但现在是卓越的解决方案。 You can make your custom builds , have a higher performance , support AMD and have great extra features . 您可以制作自定义版本 ，具有更高性能 ，支持AMD并具有强大的额外功能 。 Check this Lo-Dash vs Underscore benchmarks on jsperf and.. this awesome post about lo-dash : 检查这个关于jsperf的Lo-Dash vs Underscore 基准测试和... 关于lo-dash的这篇很棒的帖子 ：

One of the most useful feature when you work with collections, is the shorthand syntax: 使用集合时最有用的功能之一是简写语法：

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 }]

(taken from lodash docs ) （摘自lodash docs ）

---

#3楼

I created Lo-Dash to provide more consistent cross-environment iteration support for arrays, strings, objects, and arguments objects ¹ . 我创建了Lo-Dash，为数组，字符串，对象和arguments对象¹提供更一致的跨环境迭代支持。 It has since become a superset of Underscore, providing more consistent API behavior, more features (like AMD support, deep clone, and deep merge), more thorough documentation and unit tests (tests which run in Node, Ringo, Rhino, Narwhal, PhantomJS, and browsers), better overall performance and optimizations for large arrays/object iteration, and more flexibility with custom builds and template pre-compilation utilities. 它已成为Underscore的超集，提供更一致的API行为，更多功能 （如AMD支持，深度克隆和深度合并），更全面的文档和单元测试（在Node，Ringo，Rhino，Narwhal，PhantomJS中运行的测试）和浏览器），更好的整体性能和大型数组/对象迭代的优化，以及自定义构建和模板预编译实用程序的更大灵活性。

Because Lo-Dash is updated more frequently than Underscore, a lodash underscore build is provided to ensure compatibility with the latest stable version of Underscore. 由于Lo-Dash比lodash underscore更新频繁， 因此提供了lodash underscore构建，以确保与最新稳定版本的lodash underscore兼容。

At one point I was even given push access to Underscore, in part because Lo-Dash is responsible for raising more than 30 issues; 有一次，我甚至获得了对Underscore的推动 ，部分原因是Lo-Dash负责筹集超过30个问题; landing bug fixes, new features, & perf gains in Underscore v1.4.x+. Underscore v1.4.x +中的登陆错误修复，新功能和性能提升。

In addition there are at least 3 Backbone boilerplates that include Lo-Dash by default and Lo-Dash is now mentioned in Backbone's official documentation . 此外，默认情况下至少有3个Backbone样板包含Lo-Dash，现在Backbone的官方文档中提到了Lo-Dash。

Check out Kit Cambridge's post, Say "Hello" to Lo-Dash , for a deeper breakdown on the differences between Lo-Dash and Underscore. 查看Kit Cambridge的帖子， 向Lo-Dash说“你好” ，以便更深入地分析Lo-Dash和Underscore之间的差异。

Footnotes: 脚注：

1. Underscore has inconsistent support for arrays, strings, objects, and arguments objects. Underscore对数组，字符串，对象和arguments对象的支持不一致。 In newer browsers, Underscore methods ignore holes in arrays , "Objects" methods iterate arguments objects, strings are treated as array-like, and methods correctly iterate functions (ignoring their "prototype" property) and objects (iterating shadowed properties like "toString" and "valueOf"), while in older browsers they will not. 在较新的浏览器中，Underscore方法忽略数组中的漏洞 ，“Objects”方法迭代arguments对象，字符串被视为类似数组，方法正确迭代函数（忽略它们的“原型”属性）和对象（迭代阴影属性，如“toString”）和“valueOf”），而在较旧的浏览器中他们不会。 Also, Underscore methods like _.clone preserve holes in arrays, while others like _.flatten don't. 此外，像_.clone这样的_.clone方法_.clone保留数组中的漏洞，而像_.flatten这样的其他_.flatten则不会。

---

#4楼

In addition to John's answer, and reading up on lodash (which I had hitherto regarded as a "me-too" to underscore), and seeing the performance tests, reading the source-code, and blog posts , the few points which make lodash much superior to underscore are these: 除了John的回答，还读起lodash（我迄今为止被认为是“me-too”以强调），并看到性能测试，阅读源代码和博客文章 ，使得lodash的几个要点这些更优于下划线：

1. It's not about the speed, as it is about consistency of speed (?) 这不是关于速度，而是关于速度的一致性 （？）

   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. Firefox的某些功能非常快，而且在一些Chrome中占主导地位。 (I imagine there would be some scenarios where IE would dominate too). （我想有一些情况下IE也会占据主导地位）。 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! 我现在惊呆了，看到一个lodash比简单的 原生功能（如Chrome中的Array.every快了100-150％！

2. The extras in lodash are also quite useful. lodash中的附加功能也非常有用。

3. As for Xananax's highly upvoted comment suggesting contribution to underscore's code: It's always better to have GOOD competition, not only does it keep innovation going, but also drives you to keep yourself (or your library) in good shape. 至于Xananax的高评价意见表明对下划线代码的贡献：拥有良好的竞争总是更好，它不仅能保持创新，还能促使你保持自己（或你的图书馆）的良好状态。

Here is a list of differences between lodash, and it's underscore-build is a drop-in replacement for your underscore projects. 以下是lodash之间的差异列表 ，它的下划线构建是您的下划线项目的直接替代品。

---

#5楼

This is 2014 and a couple of years too late. 这是2014年，而且已经太晚了几年。 Still I think my point holds: 我仍然认为我的观点是：

IMHO this discussion got blown out of proportion quite a bit. 恕我直言，这次讨论相当不成比例。 Quoting the aforementioned blog post : 引用上述博文 ：

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. 大多数JavaScript实用程序库（例如Underscore，Valentine和wu）都依赖于“本机优先的双重方法”。这种方法更喜欢本机实现，只有在不支持本机等效时才会回归到vanilla JavaScript。 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. 但jsPerf揭示了一个有趣的趋势：迭代数组或类似数组的最有效方法是完全避免本机实现，而选择简单的循环。

As if "simple loops" and "vanilla Javascript" are more native than Array or Object method implementations. 好像“简单循环”和“vanilla Javascript”比Array或Object方法实现更本地化。 Jeez ... Jeez ......

It certainly would be nice to have a single source of truth, but there isn't. 拥有单一的事实来源肯定会很好，但事实并非如此。 Even if you've been told otherwise, there is no Vanilla God, my dear. 即使你已被告知，亲爱的，也没有香草神。 I'm sorry. 对不起。 The only assumption that really holds is that we are all writing Javascript code that aims at performing well in all major browsers, knowing that all of them have different implementations of the same things. 唯一真正成立的假设是我们都在编写旨在在所有主流浏览器中都表现良好的Javascript代码，因为他们都知道所有这些代码都有不同的实现。 It's a bitch to cope with, to put it mildly. 温和地说，这是一个应对的婊子。 But that's the premise, whether you like it or not. 但这是前提，无论你喜不喜欢。

Maybe y'all are working on large scale projects that need twitterish performance so that you really see the difference between 850,000 (underscore) vs. 2,500,000 (lodash) iterations over a list per sec right now! 也许你们都在开展大规模的项目，这些项目需要慌张的表现才能让你真正看到每秒在列表上的850,000（下划线）和2,500,000（lodash）迭代之间的差异！

I for one am not. 我不是一个人。 I mean, I worked projects where I had to address performance issues, but they were never solved or caused by neither Underscore nor Lo-Dash. 我的意思是，我工作的项目我必须解决性能问题，但它们从未解决或由Underscore和Lo-Dash引起。 And unless I get hold of the real differences in implementation and performance (we're talking C++ right now) of lets say a loop over an iterable (object or array, sparse or not!), I rather don't get bothered with any claims based on the results of a benchmark platform that is already opinionated . 除非我抓住实现和性能的真正差异（我们现在正在谈论C ++），让我们说一个循环遍及一个可迭代的（对象或数组，稀疏或不稀疏！），我宁愿不被任何困扰基于已经舆论的基准平台的结果提出索赔。

It only needs one single update of lets say Rhino to set its Array method implementations on fire in a fashion that not a single "medieval loop methods perform better and forever and whatnot" priest can argue his/her way around the simple fact that all of a sudden array methods in FF are much faster than his/her opinionated brainfuck. 它只需要一个单独的更新让我们说Rhino以一种方式设置它的Array方法实现，这种方式没有一个“中世纪循环方法表现更好，永远而且什么都不是”牧师可以围绕这个简单事实争论他/她的所有方式FF中的突然阵列方法比他/她认为的脑力快得多。 Man, you just can't cheat your runtime environment by cheating your runtime environment! 伙计，你不能通过欺骗你的运行时环境来欺骗你的运行时环境！ Think about that when promoting ... 在推广时考虑一下......

your utility belt 你的实用腰带

... next time. ... 下次。

So to keep it relevant: 所以要保持相关性：

• Use Underscore if you're into convenience without sacrificing native ish. 如果您在不牺牲原生能力的情况下进入方便，请使用Underscore。
• Use Lo-Dash if you're into convenience and like its extended feature catalogue (deep copy etc.) and if you're in desperate need of instant performance and most importantly don't mind settling for an alternative as soon as native API's outshine opinionated workaurounds. 使用Lo-Dash，如果你是方便的，并且喜欢它的扩展功能目录（深层拷贝等），如果你迫切需要即时性能，最重要的是不要介意在本机API出现时立即寻求替代方案固执己见的工作。 Which is going to happen soon. 哪个会很快发生。 Period. 期。
• There's even a third solution. 甚至还有第三种解决方案。 DIY! DIY！ Know your environments. 了解您的环境。 Know about inconsistencies. 了解不一致。 Read their ( John-David 's and Jeremy 's) code. 阅读他们（ 约翰 - 大卫和杰里米的）代码。 Don't use this or that without being able to explain why a consistency/compatibility layer is really needed and enhances your workflow or improves the performance of your app. 如果不能解释为什么真正需要一致性/兼容性层并且增强您的工作流程或提高应用程序的性能，请不要使用这个或那个。 It is very likely that your requirements are satisfied with a simple polyfill that you're perfectly able to write yourself. 很可能您的要求满足于您完全能够自己编写的简单的填充物。 Both libraries are just plain vanilla with a little bit of sugar. 这两个图书馆都是普通的香草，带有一点点糖。 They both just fight over who's serving the sweetest pie . 他们俩只是为谁最甜蜜的馅饼而战 。 But believe me, in the end both are only cooking with water. 但相信我，最后两人都只是用水做饭。 There's no Vanilla God so there can't be no Vanilla pope, right? 没有香草神，所以不可能没有香草教皇，对吗？

Choose whatever approach fits your needs the most. 选择最适合您需求的方法。 As usual. 照常。 I'd prefer fallbacks on actual implementations over opinionated runtime cheats anytime but even that seems to be a matter of taste nowadays. 我更喜欢在实际的实现上回落而不是固执的运行时作弊，但即便如此，这似乎也是现在的品味问题。 Stick to quality resources like http://developer.mozilla.com and http://caniuse.com and you'll be just fine. 坚持像http://developer.mozilla.com和http://caniuse.com这样的优质资源，你会很好。

---

#6楼

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

Latest article comparing the two by Ben McCormick: Ben McCormick将两者进行比较的最新文章：

1. Lo-Dash's API is a superset of Underscore's. Lo-Dash的API是Underscore的超集。

2. Under the hood [Lo-Dash] has been completely rewritten. 引擎盖下[Lo-Dash]已被完全重写。

3. Lo-Dash is definitely not slower than Underscore. Lo-Dash肯定不比Underscore慢。

4. What has Lo-Dash added? Lo-Dash添加了什么？

   • Usability Improvements 可用性改进
   • Extra Functionality 额外功能
   • Performance Gains 业绩增长
   • Shorthand syntaxes for chaining 链接的简写语法
   • Custom Builds to only use what you need 自定义构建仅使用您需要的内容
   • Semantic versioning and 100% code coverage 语义版本控制和100％代码覆盖率