为什么有人更喜欢lodash.js或underscore.js实用程序库而不是另一个？
Lodash似乎是下划线的替代品，后者已经存在了更长时间 .
我认为两者都很精彩，但我对他们如何努力进行有根据的比较并不了解，我想更多地了解这些差异 .
Lo-Dash的灵感来自下划线，但现在是卓越的解决方案 . 你可以让custom builds，higher performance，支持AMD并拥有great extra features . 检查jsperf上的Lo-Dash vs Underscore benchmarks和..这个awesome post about lo-dash：
使用集合时最有用的功能之一是简写语法：
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 docs）
lodash 已经 _.mapValues() 与underescore的 _.mapObject() 相同 .
_.mapValues()
_.mapObject()
我创建了Lo-Dash，为数组，字符串，对象和 arguments objects1提供更一致的跨环境迭代支持 . 它已成为Underscore的超集，提供更一致的API行为，更多features（如AMD支持，深度克隆和深度合并），更彻底的documentation和单元测试（在Node，Ringo，Rhino，Narwhal，PhantomJS中运行的测试）和浏览器），更好的整体性能和大型数组/对象迭代的优化，以及custom builds和模板预编译实用程序的更大灵活性 .
arguments
因为Lo-Dash比Underscore更频繁地更新，所以 lodash underscore build is provided以确保与最新稳定版本的Underscore兼容 .
lodash underscore
有一次我甚至给了Underscore push access，部分是因为Lo-Dash负责筹集超过30个问题; Underscore v1.4.x中的登陆错误修复，新功能和性能提升 .
此外，默认情况下至少有3个Backbone样板包含Lo-Dash，现在Backbone的官方documentation中提到了Lo-Dash .
查看Kit Cambridge的帖子，Say "Hello" to Lo-Dash，了解Lo-Dash和Underscore之间差异的更深层次细分 .
脚注：
_.clone
_.flatten
http://benmccormick.org/2014/11/12/underscore-vs-lodash/
Ben McCormick将两者进行比较的最新文章：
Lo-Dash的API是Underscore的超集 . 引擎盖下[Lo-Dash]已被完全重写 . Lo-Dash肯定不比Underscore慢 . Lo-Dash添加了什么？可用性改进额外功能性能获得用于链接自定义构建的简写语法，仅使用您需要的语义版本控制和100％代码覆盖率
如果像我一样，你期待下划线和lodash之间的使用差异列表，那就是guide for migrating from underscore to lodash .
以下是后人的当前状态：
下划线_.compose是Lodash .flowRight下划线.contains是Lodash .includes下划线.findWhere是Lodash .find下划线.invoke是Lodash .invokeMap下划线.mapObject是Lodash .mapValues下划线.pluck是Lodash .map Underscore .where是Lodash .filter下划线.any是Lodash .some下划线.all是Lodash .every下划线.each不允许通过返回false退出Underscore .flatten是深默认情况下，当Lodash浅时，Underscore .isFinite与Number.isFinite不对齐（例如.isFinite（'1'）在Underscore中返回true但在Lodash中返回false）Underscore .matches简写不支持深度比较（例如.filter（objects，{'a'：{'b'：'c'}}））Underscore≥1.7＆Lodash已将其.template语法更改为.template（字符串，选项）（数据）Lodash _ . uniq不接受像Underscore那样的迭代函数 . 使用Lodash .uniqBy Lodash .first和.last不接受像Underscore那样的n参数 . 使用切片Lodash .memoize高速缓存是像对象一样的 Map Lodash支持隐式链接，懒惰链接和快捷方式融合Lodash将其重载的.head，.last，.rest，＆.initial分割为.take，_ . takeRight，. drop，＆. dropRight（即Underscore中的_.head（array，2）在Lodash中是_.take（array，2））
不确定这是不是OP意味着什么，但我遇到了这个问题，因为我正在搜索从下划线迁移到lodash时我必须记住的问题列表 .
如果有人发布了一篇包含这些差异的完整列表的文章，我将非常感激 . 让我从我学到的东西开始（也就是说，使我的代码在 生产环境 中爆炸的东西：/）：
默认情况下，下划线中的
_.flatten 是深的，你必须传递true作为第二个参数才能使其变浅 . 在lodash它默认是浅的，并且传递true作为第二个参数会使它变深！ :)下划线中的
_.last 接受第二个参数，该参数表示您想要多少个元素 . 在 lodash 中没有这样的选择 . 您可以使用 .slice 模拟此
_.last
lodash
.slice
_.first （同一期）下划线中的
_.first
_.template 可以以多种方式使用，其中一种方式是提供模板字符串和数据并返回 HTML （或者至少它是以前的工作方式） . 在 lodash 中，您会收到一个函数，然后您应该使用该数据 .
_.template
HTML
_(something).map(foo) 在下划线中工作，但在lodash中我不得不将其重写为 _.map(something,foo) . 也许这只是一个 TypeScript -issue
_(something).map(foo)
_.map(something,foo)
TypeScript
在大多数情况下，下划线是lodash的子集 . 有时，像目前的下划线将有很酷的小函数lodash没有像mapObject . 这个节省了我很多时间来开发我的项目 .
我刚发现一个差异最终对我很重要 . lodash的 _.extend() 的非下划线兼容版本不会复制类级别定义的属性或方法 .
_.extend()
我在CoffeeScript中创建了一个Jasmine测试来演示：
https://gist.github.com/softcraft-development/1c3964402b099893bd61
幸运的是， lodash.underscore.js 保留了Underscore复制所有内容的行为，这对我的情况来说是理想的行为 .
lodash.underscore.js
除了John的答案，并阅读lodash（我迄今为止被认为是"me-too"以强调），并看到性能测试，阅读源代码和blog posts，使得lodash远远超出下划线的几点是这些：
如果你看一下下划线的源代码，你会在前几行看到下划线回落到许多函数的本机实现上 . 虽然在一个理想的世界中，这将是一个更好的方法，如果你看一下这些幻灯片中给出的一些性能链接，不难得出这些“原生实现”的质量变化很大的结论 - 到浏览器 . Firefox的一些功能很快，而且在一些Chrome中占主导地位 . （我想在某些场景中IE也会占据主导地位） . 我相信最好选择性能在浏览器中更加一致的代码 . 请先阅读博客文章，而不是相信它，而是通过运行基准来判断自己 . 我现在很震惊，看到一个lodash比简单的原生功能（如Chrome中的Array.every）快了100-150％！
lodash中的 extras 也非常有用 .
至于Xananax 's highly upvoted comment suggesting contribution to underscore'代码：拥有 GOOD 竞争总是更好，不仅可以保持创新，还可以让你保持自己（或你的图书馆）的良好状态 .
这是lodash之间的list of differences，它的下划线构建是您的下划线项目的直接替代品 .
我同意这里所说的大部分内容，但我只想指出支持underscore.js的论证：库的大小 .
特别是在您开发打算主要在移动设备上使用的应用程序或网站时，生成的捆绑包的大小以及对启动或下载时间的影响可能起着重要作用 .
为了比较，这些大小是我在运行离子发送后使用source-map-explorer注意到的：
lodash: 523kB underscore.js: 51.6kb
这是2014年，而且已经太晚了几年 . 我仍然认为我的观点是：
恕我直言，这次讨论相当不成比例 . 引用前面提到的blog post：
大多数JavaScript实用程序库，例如Underscore，Valentine和wu，都依赖于“本机优先的双重方法 . ”这种方法更喜欢本机实现，只有在不支持本机等效时才会回归到vanilla JavaScript . 但jsPerf揭示了一个有趣的趋势：迭代数组或类似数组的最有效方法是完全避免本机实现，而是选择简单的循环 .
好像“简单循环”和“vanilla Javascript”比Array或Object方法实现更本地化 . Jeez ......
拥有单一的事实来源肯定会很好，但事实并非如此 . 即使你被告知，亲爱的，也没有香草神 . 对不起 . 唯一真正成立的假设是我们都在编写旨在在所有主流浏览器中都表现良好的Javascript代码，因为他们都知道所有浏览器都有不同的实现 . 温和地说，这是一个应对的婊子 . 但这是前提，无论你喜不喜欢 .
也许你们都在开展需要慌张表现的大型项目，这样你们才能真正看到差异between 850,000 (underscore) vs. 2,500,000 (lodash) iterations over a list per sec！
我一个人不是 . 我的意思是，我工作的项目我必须解决性能问题，但它们从未解决或由Underscore和Lo-Dash引起 . 除非我 grab 真实的东西实施和绩效的差异（基于is already opinionated的基准平台的结果，我们对任何索赔感到困扰 .
它只需要一个单独的更新，让我们说Rhino以一种方式设置其Array方法实现，这种方式不是一个“中世纪循环方法表现更好，永远而且什么都不是”牧师可以围绕一个简单的事实争论他/她的方式所有FF中的突然阵列方法比他/她认为的脑力训练要快得多 . 伙计，你不能通过欺骗你的运行时环境来欺骗你的运行时环境！在宣传时考虑一下......
你的实用腰带
... 下次 .
所以要保持相关性：
如果您在不牺牲原生能力的情况下进入方便，请使用下划线 .
如果你迫切需要即时表演，那么就使用Lo-Dash，最重要的是，不要过于自信的工作 . 这很快就会发生 . 期 .
甚至还有第三种解决方案 . DIY！了解您的环境 . 了解不一致 . 阅读他们（John-David和Jeremy 's) code. Don' t使用这个或那个，但不能解释为什么真正需要一致性/兼容性层，并增强您的工作流程或提高您的应用程序的性能 . 很可能您的要求满意一个简单的polyfill，你完全可以自己写 . 这两个库只是普通的香草，含有一点糖.They both just fight over who's serving the sweetest pie . 但请相信我，最后两者都只是用水做饭 . 那里没有香草教皇，对？
选择最适合您需求的方法 . 照常 . 我更喜欢在实际的实现上回落而不是固执的运行时作弊，但即便如此，这似乎也是现在的品味问题 . 坚持像http://developer.mozilla.com和http://caniuse.com这样的优质资源，你会很好的 .
11 回答
Lo-Dash的灵感来自下划线，但现在是卓越的解决方案 . 你可以让custom builds，higher performance，支持AMD并拥有great extra features . 检查jsperf上的Lo-Dash vs Underscore benchmarks和..这个awesome post about lo-dash：
使用集合时最有用的功能之一是简写语法：
（摘自lodash docs）
lodash 已经
_.mapValues()与underescore的_.mapObject()相同 .我创建了Lo-Dash，为数组，字符串，对象和
argumentsobjects1提供更一致的跨环境迭代支持 . 它已成为Underscore的超集，提供更一致的API行为，更多features（如AMD支持，深度克隆和深度合并），更彻底的documentation和单元测试（在Node，Ringo，Rhino，Narwhal，PhantomJS中运行的测试）和浏览器），更好的整体性能和大型数组/对象迭代的优化，以及custom builds和模板预编译实用程序的更大灵活性 .因为Lo-Dash比Underscore更频繁地更新，所以
lodash underscorebuild is provided以确保与最新稳定版本的Underscore兼容 .有一次我甚至给了Underscore push access，部分是因为Lo-Dash负责筹集超过30个问题; Underscore v1.4.x中的登陆错误修复，新功能和性能提升 .
此外，默认情况下至少有3个Backbone样板包含Lo-Dash，现在Backbone的官方documentation中提到了Lo-Dash .
查看Kit Cambridge的帖子，Say "Hello" to Lo-Dash，了解Lo-Dash和Underscore之间差异的更深层次细分 .
脚注：
arguments对象的支持不一致 . 在较新的浏览器中，Underscore方法忽略holes in arrays，"Objects"方法迭代arguments对象，字符串被视为类似数组，方法正确迭代函数（忽略它们的"prototype"属性）和对象（迭代阴影属性，如"toString"和"valueOf"），而在旧版浏览器中他们不会 . 此外，像_.clone这样的Underscore方法会保留数组中的漏洞，而像_.flatten这样的其他方法则不会 .http://benmccormick.org/2014/11/12/underscore-vs-lodash/
Ben McCormick将两者进行比较的最新文章：
如果像我一样，你期待下划线和lodash之间的使用差异列表，那就是guide for migrating from underscore to lodash .
以下是后人的当前状态：
不确定这是不是OP意味着什么，但我遇到了这个问题，因为我正在搜索从下划线迁移到lodash时我必须记住的问题列表 .
如果有人发布了一篇包含这些差异的完整列表的文章，我将非常感激 . 让我从我学到的东西开始（也就是说，使我的代码在 生产环境 中爆炸的东西：/）：
默认情况下，下划线中的
_.flatten是深的，你必须传递true作为第二个参数才能使其变浅 . 在lodash它默认是浅的，并且传递true作为第二个参数会使它变深！ :)下划线中的
_.last接受第二个参数，该参数表示您想要多少个元素 . 在lodash中没有这样的选择 . 您可以使用.slice模拟此_.first（同一期）下划线中的
_.template可以以多种方式使用，其中一种方式是提供模板字符串和数据并返回HTML（或者至少它是以前的工作方式） . 在lodash中，您会收到一个函数，然后您应该使用该数据 ._(something).map(foo)在下划线中工作，但在lodash中我不得不将其重写为_.map(something,foo). 也许这只是一个TypeScript-issue在大多数情况下，下划线是lodash的子集 . 有时，像目前的下划线将有很酷的小函数lodash没有像mapObject . 这个节省了我很多时间来开发我的项目 .
我刚发现一个差异最终对我很重要 . lodash的
_.extend()的非下划线兼容版本不会复制类级别定义的属性或方法 .我在CoffeeScript中创建了一个Jasmine测试来演示：
https://gist.github.com/softcraft-development/1c3964402b099893bd61
幸运的是，
lodash.underscore.js保留了Underscore复制所有内容的行为，这对我的情况来说是理想的行为 .除了John的答案，并阅读lodash（我迄今为止被认为是"me-too"以强调），并看到性能测试，阅读源代码和blog posts，使得lodash远远超出下划线的几点是这些：
lodash中的 extras 也非常有用 .
至于Xananax 's highly upvoted comment suggesting contribution to underscore'代码：拥有 GOOD 竞争总是更好，不仅可以保持创新，还可以让你保持自己（或你的图书馆）的良好状态 .
这是lodash之间的list of differences，它的下划线构建是您的下划线项目的直接替代品 .
我同意这里所说的大部分内容，但我只想指出支持underscore.js的论证：库的大小 .
特别是在您开发打算主要在移动设备上使用的应用程序或网站时，生成的捆绑包的大小以及对启动或下载时间的影响可能起着重要作用 .
为了比较，这些大小是我在运行离子发送后使用source-map-explorer注意到的：
这是2014年，而且已经太晚了几年 . 我仍然认为我的观点是：
恕我直言，这次讨论相当不成比例 . 引用前面提到的blog post：
好像“简单循环”和“vanilla Javascript”比Array或Object方法实现更本地化 . Jeez ......
拥有单一的事实来源肯定会很好，但事实并非如此 . 即使你被告知，亲爱的，也没有香草神 . 对不起 . 唯一真正成立的假设是我们都在编写旨在在所有主流浏览器中都表现良好的Javascript代码，因为他们都知道所有浏览器都有不同的实现 . 温和地说，这是一个应对的婊子 . 但这是前提，无论你喜不喜欢 .
也许你们都在开展需要慌张表现的大型项目，这样你们才能真正看到差异between 850,000 (underscore) vs. 2,500,000 (lodash) iterations over a list per sec！
我一个人不是 . 我的意思是，我工作的项目我必须解决性能问题，但它们从未解决或由Underscore和Lo-Dash引起 . 除非我 grab 真实的东西实施和绩效的差异（基于is already opinionated的基准平台的结果，我们对任何索赔感到困扰 .
它只需要一个单独的更新，让我们说Rhino以一种方式设置其Array方法实现，这种方式不是一个“中世纪循环方法表现更好，永远而且什么都不是”牧师可以围绕一个简单的事实争论他/她的方式所有FF中的突然阵列方法比他/她认为的脑力训练要快得多 . 伙计，你不能通过欺骗你的运行时环境来欺骗你的运行时环境！在宣传时考虑一下......
... 下次 .
所以要保持相关性：
如果您在不牺牲原生能力的情况下进入方便，请使用下划线 .
如果你迫切需要即时表演，那么就使用Lo-Dash，最重要的是，不要过于自信的工作 . 这很快就会发生 . 期 .
甚至还有第三种解决方案 . DIY！了解您的环境 . 了解不一致 . 阅读他们（John-David和Jeremy 's) code. Don' t使用这个或那个，但不能解释为什么真正需要一致性/兼容性层，并增强您的工作流程或提高您的应用程序的性能 . 很可能您的要求满意一个简单的polyfill，你完全可以自己写 . 这两个库只是普通的香草，含有一点糖.They both just fight over who's serving the sweetest pie . 但请相信我，最后两者都只是用水做饭 . 那里没有香草教皇，对？
选择最适合您需求的方法 . 照常 . 我更喜欢在实际的实现上回落而不是固执的运行时作弊，但即便如此，这似乎也是现在的品味问题 . 坚持像http://developer.mozilla.com和http://caniuse.com这样的优质资源，你会很好的 .