Différences entre lodash et soulignement

Question

Pourquoi quelqu'un préférerait-il la bibliothèque d'utilitaires lodash.js ou nderscore.js à l'autre?

Lodash semble être un remplaçant instantané du soulignement, ce dernier ayant été plus long.

Je pense que les deux sont brillants, mais je ne sais pas assez comment ils travaillent pour faire une comparaison éclairée, et j'aimerais en savoir plus sur les différences.

John-David Dalton · Accepted Answer

J'ai créé Lo-Dash pour fournir une prise en charge plus cohérente des itérations entre environnements pour les tableaux, les chaînes, les objets et les objets arguments.¹. Il est depuis devenu un sur-ensemble d'Underscore, offrant un comportement d'API plus cohérent, plus fonctionnalités (comme le support AMD, le clonage profond et la fusion profonde), plus complet documentation et tests unitaires (tests exécutés dans les nœuds, Ringo, Rhino, Narwhal, PhantomJS et les navigateurs), meilleures performances et optimisations globales pour l'itération de grands tableaux/objets et plus de flexibilité avec versions personnalisées et utilitaires de pré-compilation de modèles .

Comme Lo-Dash est mis à jour plus fréquemment qu'Underscore, un lodash underscore build est fourni pour assurer la compatibilité avec la dernière version stable d'Underscore.

À un moment donné, on m'a même donné accès Push à Underscore, en partie parce que Lo-Dash est responsable de la création de plus de 30 problèmes; corrections de bogues, nouvelles fonctionnalités et gains de performances dans Underscore v1.4.x +.

De plus, il existe au moins trois chaudières Backbone qui incluent Lo-Dash par défaut et Lo-Dash est maintenant mentionné dans le document officiel Backbone documentation .

Consultez le post de Kit Cambridge, dites "bonjour" à Lo-Dash , pour une analyse plus détaillée des différences entre Lo-Dash et Underscore.

Notes de bas de page:

Le soulignement a un support incohérent pour les tableaux, les chaînes, les objets et les objets arguments. Dans les nouveaux navigateurs, les méthodes Underscore ignorent trous dans les tableaux , les méthodes "Objets" parcourent arguments objets, les chaînes sont traitées comme des tableaux et les méthodes effectuent une itération correcte des fonctions (en ignorant leur propriété "prototype" ) et des objets (en itérant des propriétés ombrées telles que "toString" et "valueOf"), alors que dans les navigateurs plus anciens, ils ne le seront pas. De plus, les méthodes Underscore telles que _.clone préservent les trous dans les tableaux, tandis que d'autres, telles que _.flatten ne le font pas.

neiker · Answer

Lo-Dash est inspiré du trait de soulignement, mais constitue aujourd'hui une solution de qualité supérieure. Vous pouvez créer votre builds personnalisés , avoir un performances plus élevées , prendre en charge AMD et avoir super fonctionnalités supplémentaires . Vérifiez ceci repères Lo-Dash vs Underscore sur jsperf et .. this post génial sur lo-dash :

Une des fonctionnalités les plus utiles lorsque vous travaillez avec des collections est la syntaxe abrégée:

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

(extrait de lodash docs )

Iest · Answer

Si, comme moi, vous attendiez une liste des différences d'utilisation entre le soulignement et le lodash, il existe un guide pour la migration du soulignement vers le lodash .

Voici l'état actuel de celui-ci pour la postérité:

Soulignement _.any est Lodash _.some

Soulignement _.all est Lodash _.every

Soulignement _.compose est Lodash _.flowRight

Soulignement _.contains est Lodash _.includes

Le trait de soulignement _.each ne permet pas de quitter en renvoyant false

Soulignement _.findWhere est Lodash _.find

Le trait de soulignement _.flatten est profond par défaut alors que Lodash est peu profond

Le trait de soulignement _.groupBy prend en charge une itérée qui reçoit les paramètres (value, index, originalArray) alors que, dans Lodash, la itérée de _.groupBy ne reçoit qu'un seul paramètre: (value).

Soulignement _.indexOf avec le 3ème paramètre undefined est Lodash _.indexOf

Soulignement _.indexOf avec le 3ème paramètre true est Lodash _.sortedIndexOf

Soulignement _.indexBy est Lodash _.keyBy

Soulignement _.invoke est Lodash _.invokeMap

Soulignement _.mapObject est Lodash _.mapValues

Underscore _.max combine Lodash _.max & _.maxBy

Underscore _.min combine Lodash _.min & _.minBy

Underscore _.sample combine Lodash _.sample & _.sampleSize

Underscore _.object combine Lodash _.fromPairs et _.zipObject

Souligner _.omit par un prédicat est Lodash _.omitBy

Soulignement _.pairs est Lodash _.toPairs

Souligner _.pick par un prédicat est Lodash _.pickBy

Soulignement _.pluck est Lodash _.map

Underscore _.sortedIndex combine Lodash _.sortedIndex & _.sortedIndexOf

Souligner _.uniq par un iteratee est Lodash _.uniqBy

Soulignement _.where est Lodash _.filter

Le trait de soulignement _.isFinite ne s’aligne pas avec Number.isFinite
(par exemple, _.isFinite('1') renvoie true en caractère de soulignement, mais false à Lodash)

Le trait de soulignement _.matches ne prend pas en charge les comparaisons approfondies
(par exemple _.filter(objects, { 'a': { 'b': 'c' } }))

Le soulignement ≥ 1,7 et la syntaxe Lodash _.template est
_.template(string, option)(data)

Lodash _.memoize les caches sont Map comme des objets

Lodash ne prend pas en charge un argument context pour de nombreuses méthodes en faveur de _.bind

Lodash prend en charge chaînage implicite , chaînage paresseux, & fusion de raccourcis

Lodash a divisé son _.head, _.last, _.rest, & _.initial surchargé en
_.take, _.takeRight, _.drop, & _.dropRight
(c'est-à-dire _.head(array, 2) dans le trait de soulignement est _.take(array, 2) dans Lodash)

kumarharsh · Answer

En plus de la réponse de John et de la lecture de lodash (ce que j’avais considéré jusqu’à présent comme un "me-trop" à souligner), de la lecture des tests de performance, de la lecture du code source et messages de blog , les quelques points qui font que lodash est bien supérieur au soulignement sont les suivants:

Ce n’est pas une question de vitesse, car il s’agit de cohérence de vitesse (?)

Si vous vous penchez sur le code source du soulignement, vous verrez dans les premières lignes que celui-ci souligne le retour en arrière des implémentations natives de nombreuses fonctions. Bien que dans un monde idéal, cela aurait été une meilleure approche. Si vous regardez quelques-uns des liens parfaits donnés dans ces diapositives , il n’est pas difficile de conclure que la qualité de ces les implémentations varient beaucoup d'un navigateur à l'autre. Firefox est sacrément rapide dans certaines fonctions et dans certaines Chrome dominent. (J'imagine qu'il y aurait des scénarios dans lesquels IE dominerait aussi). Je pense qu'il est préférable de préférer un code dont les performances sont plus cohérentes entre les navigateurs.

Lisez le billet de blog plus tôt et au lieu de le croire pour vous, jugez par vous-même en exécutant le points de repère . Je suis abasourdi de voir un lodash performer 100 à 150% plus vite qu'un soulignement dans des fonctions simples simples , telles que Array.every dans Chrome!
Les extras de lodash sont également très utiles.
En ce qui concerne le commentaire très prisé de Xananax suggérant une contribution au code du soulignement: Il est toujours préférable d’avoir UNE BONNE CONCURRENCE, non seulement elle maintient l’innovation, mais aussi vous pousse à vous garder (ou votre bibliothèque) en bonne forme.

Voici un liste des différences entre lodash, et son soulignement-construction est un remplacement instantané de vos projets de soulignement.

Lukas B&#252;nger · Answer

Nous sommes en 2014 et quelques années trop tard. Je pense toujours que mon point est vrai:

IMHO cette discussion a été époustouflée un peu. Citant ce qui précède blog post :

La plupart des bibliothèques d’utilitaires JavaScript, telles que Underscore, Valentine et wu, s’appuient sur "l’approche double native-première". Cette approche préfère les implémentations natives, ne recourant au JavaScript Vanilla que si l’équivalent natif n’est pas pris en charge. Mais jsPerf a révélé une tendance intéressante: le moyen le plus efficace d'itérer un tableau ou une collection semblable à un tableau est d'éviter complètement les implémentations natives, optant plutôt pour des boucles simples.

Comme si "simples boucles" et "Vanilla Javascript" étaient plus natifs que les implémentations de méthodes Array ou Object. Bon Dieu ...

Ce serait certainement bien d'avoir une seule source de vérité, mais il n'y en a pas. Même si on vous a dit le contraire, il n'y a pas de dieu vanille, mon cher. Je suis désolé. La seule hypothèse qui soit valable est que nous écrivons tous du code Javascript qui vise à bien fonctionner dans tous les principaux navigateurs, sachant qu'ils ont tous une implémentation différente des mêmes choses. C'est une chienne à gérer, pour le dire gentiment. Mais c'est la prémisse, que cela vous plaise ou non.

Peut-être que vous travaillez tous sur des projets à grande échelle qui ont besoin de performances Twitter afin de voir vraiment la différence entre 850 000 (soulignement) et 2 500 000 itérations sur une liste par seconde en ce moment!

Pour ma part je ne suis pas. Je veux dire, j'ai travaillé sur des projets où je devais résoudre des problèmes de performances, mais ils n'étaient jamais résolus ni causés par Underscore ni Lo-Dash. Et à moins que je ne comprenne les véritables différences d’implémentation et de performance (nous parlons de C++ à l’heure actuelle), disons une boucle sur un élément itérable (objet ou tableau, fragmenté ou non!), Je ne me dérange pas avec revendications basées sur les résultats d'une plate-forme de référence qui est déjà opinionated .

Il suffit d’une seule mise à jour, disons, de Rhino pour mettre en œuvre ses méthodes de méthode Array de manière à ce qu’aucune "méthode de boucle médiévale ne soit plus performante et à jamais, et quoi", un prêtre peut faire valoir son point de vue simplement une méthode de tableau soudain dans FF sont beaucoup plus rapides que son cerveau éculé. Man, vous ne pouvez pas tromper votre environnement d'exécution en trompant votre environnement d'exécution! Pensez à cela lors de la promotion ...

votre ceinture utilitaire

... la prochaine fois.

Donc, pour rester pertinent:

Choisissez l'approche qui correspond le mieux à vos besoins. Comme d'habitude. Je préférerais les solutions de rechange sur les mises en œuvre réelles aux tricheurs d'opinion courants, mais même cela semble être une question de goût aujourd'hui. Tenez-vous en à des ressources de qualité telles que http://developer.mozilla.com et http://caniuse.com et tout ira bien.

David Dal Busco · Answer

Je suis d'accord avec la plupart des choses énoncées ici, mais je tiens à souligner un argument en faveur de underscore.js: la taille de la bibliothèque.

Particulièrement dans le cas où vous développez une application ou un site Web destiné à être utilisé principalement sur des appareils mobiles, la taille du paquet résultant et son effet sur le temps de démarrage ou de téléchargement peuvent jouer un rôle important.

À titre de comparaison, ces tailles sont celles que j’ai remarquées avec source-map-Explorer après avoir exécuté ionic serve:

lodash: 523kB underscore.js: 51.6kb

qbolec · Answer

Je ne suis pas sûr que ce soit ce que signifie OP, mais je suis tombé sur cette question parce que je cherchais une liste de problèmes que je dois garder à l'esprit lors de la migration du soulignement vers le lodash.

J'apprécierais vraiment si quelqu'un postait un article avec une liste complète de ces différences. Permettez-moi de commencer par les choses que j'ai apprises à la dure (c'est-à-dire les choses qui ont fait exploser mon code en production: /):

_.flatten dans le trait de soulignement est profond par défaut et vous devez passer true comme second argument pour le rendre peu profond. Dans lodash, il est peu profond par défaut et passe à true car le deuxième argument le rendra plus profond! :)
_.last in underscore accepte un deuxième argument indiquant le nombre d'éléments souhaités. Dans lodash, cette option n'existe pas. Vous pouvez émuler ceci avec .slice
_.first (même problème)
_.template dans le trait de soulignement peut être utilisé de différentes manières, l'une d'elles fournissant la chaîne de modèle et les données et récupérant HTML (ou du moins c'est ainsi que cela fonctionnait il y a quelque temps). Dans lodash, vous recevez une fonction que vous devez ensuite alimenter avec les données.
_(something).map(foo) fonctionne en trait de soulignement, mais en lodash je devais le réécrire en _.map(something,foo). C’était peut-être juste un problème TypeScript-

pilau · Answer

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

Dernier article comparant les deux de Ben McCormick:

L'API de Lo-Dash est un sur-ensemble d'Underscore.

Sous le capot [Lo-Dash] a été complètement réécrit.

Lo-Dash n'est certainement pas plus lent que Underscore.

Qu'a ajouté Lo-Dash?

Améliorations de la convivialité

Fonctionnalité supplémentaire

Gains de performance

Syntaxe abrégée pour le chaînage

Constructions personnalisées pour n'utiliser que ce dont vous avez besoin

Versionnage sémantique et couverture de code à 100%

Craig Walker · Answer

Je viens de trouver une différence qui a fini par être importante pour moi. La version non compatible du trait de soulignement de _.extend() de lodash ne () ne copie pas des propriétés ou méthodes définies par le niveau de la classe.

J'ai créé un test Jasmine dans CoffeeScript qui démontre ceci:

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

Heureusement, lodash.underscore.js conserve le comportement d'Underscore consistant à tout copier, ce qui, dans mon cas, était le comportement souhaité.

artknight · Answer

lodash possède _.mapValues() qui est identique à _.mapObject() de Underescore.

rashadb · Answer

Pour la plupart, le trait de soulignement est un sous-ensemble de lodash. Parfois, comme par exemple, le soulignement aura de petites fonctions sympas, lodash n’a pas comme mapObject. Celui-ci m'a fait gagner beaucoup de temps dans le développement de mon projet.

Alireza · Answer

Ils sont assez similaires, avec Lodash prend le relais ...

Ils sont tous deux une bibliothèque d'utilitaires qui prend le monde de l'utilitaire en JavaScript ...

Apparemment Lodash est mis à jour plus régulièrement maintenant, donc plus utilisé dans les derniers projets ...

Aussi Lodash semble plus léger de quelques KB ...

Les deux ont une bonne api et doc, mais je pense que Lodash on est mieux ...

Voici une capture d'écran pour chacun des documents pour obtenir la première valeur d'un tableau ...

trait de soulignement:

lodash:

Comme les choses peuvent être mises à jour de temps en temps, il suffit de consulter leur site Web également ...

lodash

trait de soulignement