underscore.js - validate - what is lodash js




Las diferencias entre lodash y subrayado (8)

Acabo de encontrar una diferencia que terminó siendo importante para mí. La versión no subrayada del _.extend() de _.extend() no se copia sobre propiedades o métodos definidos a nivel de clase.

He creado una prueba de Jasmine en CoffeeScript que demuestra esto:

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

Afortunadamente, lodash.underscore.js conserva el comportamiento de Underscore de copiar todo, que para mi situación era el comportamiento deseado.

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

Lodash parece ser un sustituto directo del guión bajo, ya que este último ha existido por más tiempo.

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


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

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

    Si examina el código fuente del guión bajo, verá en las primeras líneas que subrayan el retroceso en las implementaciones nativas de muchas funciones. Aunque en un mundo ideal, este podría haber sido un mejor enfoque, si observa algunos de los enlaces que se muestran en estas diapositivas , no es difícil sacar 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 algunos domina Chrome. (Me imagino que habría algunos escenarios donde IE 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 antes, y en lugar de creerlo por su bien, juzgue por sí mismo ejecutando los puntos de referencia . Estoy aturdido en este momento, al ver a un lodash realizando 100-150% más rápido que el subrayado en funciones incluso simples y nativas como Array.every . ¡ Array.every en Chrome!

  2. Los extras en lodash también son bastante útiles.

  3. En cuanto al comentario altamente promocionado de Xananax que sugiere una contribución al código de subrayado: siempre es mejor tener BUENA competencia, no solo mantiene la innovación, sino que también lo impulsa a mantenerse (oa su biblioteca) en buena forma.

Aquí hay una lista de diferencias entre lodash, y su subrayado-build es un reemplazo directo para sus proyectos de subrayado.


En su mayor parte, el subrayado es subconjunto de lodash. A veces, como el subrayado actual tendrá pequeñas funciones geniales que lodash no tiene como mapObject. Este me ahorró mucho tiempo en el desarrollo de mi proyecto.


Esto es 2014 y un par de años demasiado tarde. Todavía creo que mi punto es válido:

En mi humilde opinión esta discusión se salió de la proporción un poco. Citando la entrada de blog antes mencionada:

La mayoría de las bibliotecas de utilidades de JavaScript, como Underscore, Valentine y wu, se basan en el "primer enfoque dual nativo". Este enfoque prefiere implementaciones nativas, recurriendo a JavaScript vainilla solo si el equivalente nativo no es compatible. Pero jsPerf reveló una tendencia interesante: la forma más eficiente de recorrer una matriz o una colección similar a una matriz es evitar las implementaciones nativas por completo, optando por bucles simples en su lugar.

Como si los "bucles simples" y el "Javascript de vainilla" fueran más nativos que las implementaciones de métodos de Array u Objeto. Dios ...

Ciertamente sería bueno tener una sola fuente de verdad, pero no la hay. Incluso si le han dicho lo contrario, no hay un Dios Vainilla, querida. Lo siento. El único supuesto que realmente se sostiene es que todos estamos escribiendo código Javascript que apunta a tener un buen desempeño en todos los navegadores principales, sabiendo que todos ellos tienen implementaciones diferentes de las mismas cosas. Es una perra para hacer frente, para decirlo suavemente. Pero esa es la premisa, te guste o no.

¡Quizás estén trabajando en proyectos a gran escala que necesitan un rendimiento de Twitter para que realmente vea la diferencia entre las iteraciones de 850,000 (subrayado) y las de 2,500,000 (lodash) en una lista por segundo en este momento!

Yo, por mi parte, no lo soy. Quiero decir, trabajé en proyectos en los que tuve que abordar problemas de rendimiento, pero nunca fueron resueltos ni causados ​​por el guión bajo ni por Lo-Dash. Y a menos que consiga las diferencias reales en la implementación y el rendimiento (estamos hablando de C ++ en este momento) de digamos un bucle sobre un iterable (objeto o matriz, dispersos o no!), Prefiero que no me moleste con nada. Reclamaciones basadas en los resultados de una plataforma de referencia que ya está criticada .

Solo necesita una única actualización. Digamos que Rhino prende fuego a las implementaciones de su método Array de una manera que ni un solo "método de bucle medieval funciona mejor y para siempre", y el sacerdote puede argumentar a su manera sobre el simple hecho de que todos los métodos de una matriz repentina en FF son mucho más rápidos que los de su / su opinión. ¡Hombre, simplemente no puedes engañar a tu entorno de ejecución al engañar a tu entorno de ejecución! Piensa en eso cuando promocione ...

su cinturón utilitario

... la próxima vez.

Así que para mantenerlo relevante:

  • Usa el subrayado si te gusta la conveniencia sin sacrificar el ish nativo.
  • Use Lo-Dash si le gusta la comodidad y le gusta su catálogo de funciones extendido (copia profunda, etc.) y si necesita desesperadamente un rendimiento instantáneo y, lo que es más importante, no le importa conformarse con una alternativa tan pronto como la API nativa brille. Workaurounds opinados. Lo que va a pasar pronto. Período.
  • Incluso hay una tercera solución. Bricolaje Conoce tus entornos. Saber sobre inconsistencias. Lea su código ( John-David 's y Jeremy ' s). No use esto o aquello sin poder explicar por qué una capa de consistencia / compatibilidad es realmente necesaria y mejora su flujo de trabajo o mejora el rendimiento de su aplicación. Es muy probable que sus requisitos queden satisfechos con un simple relleno de polietileno que puede escribir usted mismo perfectamente. Ambas bibliotecas son simplemente de vainilla con un poco de azúcar. Ambos se pelean por quién está sirviendo la tarta más dulce . Pero créeme, al final ambos solo se cocinan con agua. No hay un Dios de vainilla, así que no puede haber un Papa de vainilla, ¿verdad?

Elija el enfoque que más se ajuste a sus necesidades. Como siempre. Preferiría reservas en implementaciones reales en lugar de trucos de runtime opinados en cualquier momento, pero incluso eso parece ser una cuestión de gustos en la actualidad. Cumpla con recursos de calidad como http://developer.mozilla.com y http://caniuse.com y estará bien.


Lo-Dash está inspirado en el subrayado, pero hoy en día es una solución superior. Puede hacer sus compilaciones personalizadas , tener un mayor rendimiento , ser compatible con AMD y tener excelentes funciones adicionales . Verifique estos puntos de referencia Lo-Dash vs Underscore en jsperf y ... esta increíble publicación sobre lo-dash :

Una de las características más útiles cuando trabajas con colecciones, es la sintaxis abreviada:

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

(tomado de documentos de lodash )


No estoy seguro de si eso es lo que quería decir OP, pero me topé con esta pregunta porque estaba buscando una lista de problemas que tengo que tener en cuenta al migrar del subrayado al lodash.

Realmente apreciaría si alguien publicara un artículo con una lista completa de tales diferencias. Permítanme comenzar con las cosas que aprendí de la manera más difícil (es decir, las cosas que hicieron que mi código explotara en la producción: /):

  • _.flatten en el guión bajo es profundo por defecto y tienes que pasar verdadero como segundo argumento para hacerlo superficial. En lodash es superficial por defecto y pasa verdadero como segundo argumento lo hará profundo! :)
  • _.last in subrayado acepta un segundo argumento que indica cuántos elementos desea. En lodash no hay tal opción. Puedes emular esto con .slice
  • _.first (mismo problema)
  • _.template en el guión bajo se puede usar de muchas maneras, una de las cuales es proporcionar la cadena y los datos de la plantilla y recuperar HTML (o al menos así es como funcionó hace algún tiempo). En lodash usted recibe una función que luego debe alimentar con los datos.
  • _(something).map(foo) funciona en guión bajo, pero en lodash tuve que reescribirlo en _.map(something,foo) . Tal vez eso fue sólo una edición de TypeScript

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

Último artículo comparando los dos por Ben McCormick:

  1. La API de Lo-Dash es un superconjunto de Underscore.

  2. Bajo el capó [Lo-Dash] ha sido completamente reescrito.

  3. Lo-Dash definitivamente no es más lento que el guión bajo.

  4. ¿Qué ha añadido Lo-Dash?

    • Mejoras de usabilidad
    • Funcionalidad Extra
    • Ganancias de rendimiento
    • Sintaxis abreviadas para el encadenamiento.
    • Diseños personalizados para usar solo lo que necesitas
    • Versiones semánticas y cobertura de código al 100%.

lodash tiene _.mapValues() que es idéntico a _.mapObject() guiones _.mapObject() .