Diferencias entre Lodash y Underscore.js [cerrado]

¿ Por qué alguien preferiría la biblioteca de utilidades Lodash o Underscore.js sobre la otra?

Lodash parece ser un sustituto directo del guión bajo, ya que este último existe desde hace más tiempo.

Creo que ambos son brillantes, pero no sé lo suficiente sobre cómo funcionan para hacer una comparación fundamentada y me gustaría saber más sobre las diferencias.

Dec 10 '12 00:12 Brian M. Hunt

Lodash está inspirado en Underscore.js, pero hoy en día es una solución superior. Puede crear compilaciones personalizadas , tener un mayor rendimiento , ser compatible con AMD y tener excelentes funciones adicionales . Consulte estos puntos de referencia de Lodash vs. Underscore.js en jsperf y... esta increíble publicación sobre Lodash :

Una de las características más útiles cuando trabajas con colecciones es la sintaxis abreviada:
(aunque Underscore ahora también admite esta sintaxis)

var characters = [
  { 'name': 'barney', 'age': 36, 'blocked': false },
  { 'name': 'fred',   'age': 40, 'blocked': true }
];

// Using "_.filter" callback shorthand
_.filter(characters, { 'age': 36 });

// Using Underscore.js
_.filter(characters, character => character.age === 36);

// → [{ 'name': 'barney', 'age': 36, 'blocked': false }]

(tomado de la documentación de Lodash )

Dec 13 '2012 21:12 neiker

Si, como yo, esperaba una lista de diferencias de uso entre Underscore.js y Lodash, existe una guía para migrar de Underscore.js a Lodash .

Aquí está el estado actual para la posteridad:

• El guión bajo _.anyes Lodash_.some
• El guión bajo _.alles Lodash_.every
• El guión bajo _.composees Lodash_.flowRight
• El guión bajo _.containses Lodash_.includes
• El guión bajo _.eachno permite salir regresandofalse
• El guión bajo _.findWherees Lodash_.find
• El guión bajo _.flattenes profundo de forma predeterminada, mientras que Lodash es superficial
• El guión bajo _.groupByadmite un iterado al que se le pasan los parámetros (value, index, originalArray), mientras que en Lodash, al iterado _.groupBysolo se le pasa un único parámetro (value):.
• Underscore.js _.indexOfcon el tercer parámetro undefinedes Lodash_.indexOf
• Underscore.js _.indexOfcon el tercer parámetro truees Lodash_.sortedIndexOf
• El guión bajo _.indexByes Lodash_.keyBy
• El guión bajo _.invokees Lodash_.invokeMap
• El guión bajo _.mapObjectes Lodash_.mapValues
• El guión bajo _.maxcombina Lodash _.maxy_.maxBy
• El guión bajo _.mincombina Lodash _.miny_.minBy
• El guión bajo _.samplecombina Lodash _.sampley_.sampleSize
• El guión bajo _.objectcombina Lodash _.fromPairsy_.zipObject
• El guión bajo _.omitde un predicado es Lodash._.omitBy
• El guión bajo _.pairses Lodash_.toPairs
• El guión bajo _.pickde un predicado es Lodash._.pickBy
• El guión bajo _.pluckes Lodash_.map
• El guión bajo _.sortedIndexcombina Lodash _.sortedIndexy_.sortedIndexOf
• Subrayado _.uniqpor an iterateeis Lodash_.uniqBy
• El guión bajo _.wherees Lodash_.filter
• El guión bajo _.isFiniteno se alinea Number.isFinite
  (por ejemplo, _.isFinite('1')regresa trueen Underscore.js, pero falseen Lodash)
• La taquigrafía de subrayado _.matchesno admite comparaciones profundas
  (p. ej., _.filter(objects, { 'a': { 'b': 'c' } }))
• Subrayado ≥ 1,7 y _.templatela sintaxis de Lodash es
  _.template(string, option)(data)
• Los cachés de Lodash _.memoizeson Mapcomo objetos
• Lodash no apoya un contextargumento para muchos métodos a favor de_.bind
• Lodash admite encadenamiento implícito , encadenamiento diferido y fusión de atajos
• Lodash dividió su _.head, _.last, _.rest, & _.initialsobrecargado en
  _.take, _.takeRight, _.drop, & _.dropRight
  (es decir, _.head(array, 2)en Underscore.js está _.take(array, 2)en Lodash)

Jul 21 '2016 09:07 Iest

Además de la respuesta de John , y de leer sobre Lodash (que hasta ahora había considerado como un "yo también" para Underscore.js), y de ver las pruebas de rendimiento, leer el código fuente y las publicaciones del blog , los pocos puntos que Lodash es muy superior a Underscore.js son estos:

1. No se trata de la velocidad, sino de la consistencia de la velocidad (?)

Si observa el código fuente de Underscore.js, verá en las primeras líneas que Underscore.js recurre a las implementaciones nativas de muchas funciones. Aunque en un mundo ideal, este habría sido un mejor enfoque, si observa algunos de los enlaces de rendimiento que aparecen en estas diapositivas , no es difícil llegar a la conclusión de que la calidad de esas "implementaciones nativas" varía mucho en el navegador. al navegador. Firefox es muy rápido en algunas de las funciones y en algunas domina Chrome. (Me imagino que habría algunos escenarios en los que Internet Explorer también dominaría). Creo que es mejor preferir un código cuyo rendimiento sea más consistente en todos los navegadores.

Lea la publicación del blog anteriormente y, en lugar de creerlo porque sí, juzgue usted mismo ejecutando los puntos de referencia . Estoy atónito en este momento al ver que Lodash funciona entre un 100 y un 150 % más rápido que Underscore.js incluso en funciones nativas simples , como en Chrome.Array.every

2. Los extras de Lodash también son bastante útiles.
3. En cuanto al comentario altamente votado de Xananax que sugiere una contribución al código de Underscore.js: Siempre es mejor tener BUENA competencia, no solo mantiene la innovación, sino que también te impulsa a mantenerte a ti mismo (o a tu biblioteca) en buena forma.

Aquí hay una lista de diferencias entre Lodash, y su compilación Underscore.js es un reemplazo directo para sus proyectos Underscore.js.

Aug 18 '2013 14:08 kumarharsh

En 2014 sigo pensando que mi punto es válido:

En mi humilde opinión, esta discusión se desproporcionó bastante. Citando la publicación del blog antes mencionada :

La mayoría de las bibliotecas de utilidades de JavaScript, como Underscore, Valentine y wu, se basan en el "enfoque dual nativo primero". Este enfoque prefiere implementaciones nativas y recurre a JavaScript básico solo si no se admite el equivalente nativo. Pero jsPerf reveló una tendencia interesante: la forma más eficiente de iterar sobre una matriz o una colección similar a una matriz es evitar por completo las implementaciones nativas y optar por bucles simples.

Como si los "bucles simples" y el "Javascript básico" fueran más nativos que las implementaciones de métodos de matriz u objeto. Dios...

Ciertamente sería bueno tener una única fuente de verdad, pero no la hay. Incluso si te han dicho lo contrario, no existe el Dios vainilla, querida. Lo lamento. La única suposición que realmente se cumple es que todos escribimos código JavaScript cuyo objetivo es funcionar bien en los principales navegadores, sabiendo que todos ellos tienen diferentes implementaciones de las mismas cosas. Es difícil afrontarlo, por decirlo suavemente. Pero esa es la premisa, te guste o no.

¡Quizás todos ustedes estén trabajando en proyectos a gran escala que necesitan un rendimiento similar al de Twitter para que realmente puedan ver la diferencia entre 850.000 (Underscore.js) y 2.500.000 (Lodash) iteraciones en una lista por segundo ahora mismo!

Por mi parte, no lo soy. Quiero decir, trabajé en proyectos en los que tenía que abordar problemas de rendimiento, pero nunca fueron resueltos ni causados ​​por Underscore.js ni Lodash. Y a menos que entienda las diferencias reales en implementación y rendimiento (estamos hablando de C++ en este momento) de, digamos, un bucle sobre un iterable (objeto o matriz, ¡disperso o no!), prefiero no molestarme. con cualquier reclamo basado en los resultados de una plataforma de referencia que ya tiene opiniones .

Sólo necesita una única actualización de, digamos, Rhino para prender fuego a sus implementaciones de métodos Array de una manera que ni un solo sacerdote de "métodos de bucle medieval funcionen mejor y para siempre y todo eso" pueda argumentar el simple hecho de que De repente, los métodos de matriz en Firefox son mucho más rápidos que su obstinado cerebro. ¡Hombre, simplemente no puedes engañar a tu entorno de ejecución engañando a tu entorno de ejecución! Piensa en eso a la hora de promocionar...

tu cinturón de herramientas

... La próxima vez.

Entonces, para que siga siendo relevante:

• Utilice Underscore.js si le gusta la comodidad sin sacrificar el estilo nativo.
• Utilice Lodash si le gusta la comodidad y le gusta su catálogo de funciones ampliado (copia profunda, etc.) y si necesita desesperadamente un rendimiento instantáneo y, lo más importante, no le importa conformarse con una alternativa tan pronto como las API nativas eclipsen a las obstinadas. soluciones alternativas. Lo cual va a suceder pronto. Período.
• Incluso hay una tercera solución. ¡Hazlo tú mismo! Conozca sus entornos. Conozca las inconsistencias. Lea su código ( John-David y Jeremy ). No utilice esto o aquello sin poder explicar por qué una capa de coherencia/compatibilidad es realmente necesaria y mejora su flujo de trabajo o mejora el rendimiento de su aplicación. Es muy probable que tus necesidades queden satisfechas con un simple polyfill que eres perfectamente capaz de escribir tú mismo. Ambas bibliotecas son simplemente vainilla con un poco de azúcar. Ambos simplemente pelean por quién sirve el pastel más dulce . Pero créanme, al final ambos se cocinan sólo con agua. No existe un Dios vainilla, por lo que no puede haber un Papa vainilla, ¿verdad?

Elija el enfoque que mejor se adapte a sus necesidades. Como siempre. Preferiría recurrir a implementaciones reales en lugar de trucos obstinados en tiempo de ejecución en cualquier momento, pero incluso eso parece ser una cuestión de gustos hoy en día. Cíñete a recursos de calidad como http://developer.mozilla.com y http://caniuse.com y todo irá bien.

Sep 11 '2014 21:09 Lukas Bünger

Estoy de acuerdo con la mayoría de las cosas que se dicen aquí, pero solo quiero señalar un argumento a favor de Underscore.js: el tamaño de la biblioteca.

Especialmente en caso de que esté desarrollando una aplicación o un sitio web que pretenda usarse principalmente en dispositivos móviles, el tamaño del paquete resultante y el efecto en el tiempo de arranque o descarga pueden tener un papel importante.

A modo de comparación, estos tamaños son los que noté con source-map-explorer después de ejecutar Ionicserve :

Lodash: 523 kB
Underscore.js: 51.6 kB

Se puede utilizar BundlePhobia para comprobar el tamaño actual de Lodash y Underscore.js .

Apr 26 '2017 14:04 David Dal Busco