Question Différences entre lodash et underscore


Pourquoi quelqu'un préfèrerait soit le lodash.js ou underscore.js bibliothèque utilitaire sur l'autre?

Lodash semble être un remplaçant pour underscore, 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.


1400
2017-12-09 17:08


origine


Réponses:


J'ai créé Lo-Dash pour fournir un support d'itération inter-environnements plus cohérent pour les tableaux, les chaînes, les objets et arguments objets1. Il est depuis devenu un surensemble de Underscore, fournissant un comportement API plus cohérent, plus fonctionnalités (comme le support d'AMD, le clonage profond et la fusion profonde), plus approfondi Documentation et des tests unitaires (tests qui s'exécutent dans Node, Ringo, Rhino, Narwhal, PhantomJS et les navigateurs), de meilleures performances globales et des optimisations pour les grandes arrays / itérations d'objets, et plus de flexibilité avec builds personnalisés et les utilitaires de pré-compilation de gabarits.

Parce que Lo-Dash est mis à jour plus fréquemment que Underscore, un lodash underscore construire est fourni pour assurer la compatibilité avec la dernière version stable de Underscore.

À un moment donné, on m'a même donné pousser l'accès à Underscore, en partie parce que Lo-Dash est responsable de la publication de plus de 30 numéros; les corrections de bugs d'atterrissage, les nouvelles fonctionnalités et les gains de performance dans Underscore v1.4.x +.

De plus, il y a au moins 3 cartes standard Backbone qui incluent Lo-Dash par défaut et Lo-Dash est maintenant mentionné dans le document officiel de Backbone. Documentation.

Découvrez la publication 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

  1. Underscore a un support incohérent pour les tableaux, les chaînes, les objets et arguments objets. Dans les nouveaux navigateurs, les méthodes Underscore ignorent trous dans les tableaux, Les méthodes "objets" itèrent arguments objets, les chaînes sont traitées comme des tableaux, et les méthodes itèrent correctement les fonctions (ignorant leur propriété "prototype") et les objets (itérations des propriétés ombrées comme "toString" et "valueOf"), mais pas dans les anciens navigateurs. Aussi, Underscore méthodes comme _.clone préserver les trous dans les tableaux, tandis que d'autres aiment _.flatten ne fais pas ça.

1777
2017-12-16 05:34



Lo-Dash est inspiré par le soulignement, mais de nos jours, c'est une solution supérieure. Vous pouvez faire votre builds personnalisés, avoir un performance supérieure, soutenir AMD et avoir excellentes fonctionnalités supplémentaires. Vérifie ça Lo-Dash vs Underscore repères sur jsperf et .. ce super article sur lo-dash:

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

(pris à partir de Docs lodash)


165
2017-12-13 21:51



En plus de la réponse de John, et en lisant sur lodash (que j'avais jusqu'alors considéré comme un "moi-trop" pour souligner), et en voyant les tests de performance, en lisant le code source, et articles de blog, les quelques points qui rendent le lodash bien supérieur au soulignement sont ceux-ci:

  1. Il ne s'agit pas de la vitesse, car il s'agit de cohérence de vitesse (?)

    Si vous regardez dans le code source de underscore, vous verrez dans les premières lignes que underscore retombe sur les implémentations natives de nombreuses fonctions. Bien que dans un monde idéal, cela aurait été une meilleure approche, si vous regardez certains des liens perf donnés dans ces diapositives, il n'est pas difficile de tirer la conclusion que la qualité de ces 'implémentations natives' varie beaucoup d'un navigateur à l'autre. Firefox est sacrément rapide dans certaines fonctions, et dans certains domine Chrome. (J'imagine qu'il y aurait des scénarios où IE dominerait aussi). Je crois qu'il vaut mieux préférer un code dont performance est plus cohérent entre les navigateurs.

    Lisez le billet du blog plus tôt, et au lieu de le croire pour son bien, jugez par vous-même en lançant le repères. Je suis stupéfait en ce moment, voyant un lodash effectuant 100-150% plus vite que le trait de soulignement dans même simple, originaire de des fonctions telles que Array.every dans Chrome!

  2. le extras en lodash sont également très utiles.

  3. Quant au commentaire très valorisé de Xananax suggérant une contribution au code de underscore: il vaut toujours mieux avoir BIEN la concurrence, non seulement maintient-elle l'innovation, mais vous pousse aussi à vous maintenir (ou votre bibliothèque) en bonne forme.

Voici une liste des différences entre lodash, et c'est underscore-build est un remplacement de vos projets de soulignement.


57
2017-08-18 14:18



Si comme moi vous attendiez la liste des différences d'utilisation entre underscore et lodash, il y a un guide pour la migration de underscore à lodash.

Voici l'état actuel de la situation pour la postérité:

  • Souligner _.compose est Lodash _.flowRight
  • Souligner _.contains est Lodash _.includes
  • Souligner _.findWhere est Lodash _.find
  • Souligner _.invoke est Lodash _.invokeMap
  • Souligner _.mapObject est Lodash _.mapValues
  • Souligner _.pluck est Lodash _.map
  • Souligner _.where est Lodash _.filter
  • Souligner _.any est Lodash _.some
  • Souligner _.all est Lodash _.every
  • Souligner _.each ne permet pas de sortir en retournant false
  • Souligner _.flatten est profond par défaut alors que Lodash est peu profond
  • Souligner _.isFinite ne s'aligne pas avec Number.isFinite
       (par exemple. _.isFinite('1') résultats true en Underscore mais false dans   Lodash)
  • Souligner _.matches sténographie ne supporte pas les comparaisons profondes
       (par exemple. _.filter(objects, { 'a': { 'b': 'c' } }))
  • Underscore ≥ 1.7 & Lodash ont changé leur _.template syntaxe à
    _.template(string, option)(data)
  • Lodash _.uniq n'accepte pas iteratee fonctionne comme Underscore. Utiliser Lodash _.uniqBy
  • Lodash _.first et ._last n'accepte pas un n argument comme Underscore. Utilisation slice
  • Lodash _.memoize les caches sont Map comme des objets
  • Lodash soutient chaînage implicite, chaînage paresseux, et raccourci   la fusion
  • Lodash divisé son surchargé _.head, _.last, _.rest, & _.initial dans
      _.take, _.takeRight, _.drop, &    _.dropRight
       (c'est à dire. _.head(array, 2) en Underscore est    _.take(array, 2) à Lodash)

55
2017-07-21 09:35



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

À mon humble avis, cette discussion a été un peu hors de proportion. Citant le susmentionné article de blog:

La plupart des bibliothèques d'utilitaires JavaScript, telles que Underscore, Valentine et   wu, s'appuyer sur la «double approche native-première». Cette approche préfère   implémentations natives, retombant à JavaScript vanilla seulement si le   L'équivalent natif n'est pas pris en charge. Mais jsPerf a révélé une intéressante   tendance: le moyen le plus efficace d'itérer sur un tableau ou un tableau   la collection est d'éviter complètement les implémentations natives, en optant pour   des boucles simples à la place.

Comme si les "boucles simples" et "vanilla Javascript" sont plus natives que les implémentations de méthodes Array ou Object. Jeez ...

Ce serait certainement bien d'avoir une seule source de vérité, mais ce n'est pas le cas. 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 prévaut est que nous écrivons tous du code Javascript qui vise à bien fonctionner dans tous les principaux navigateurs, sachant que tous ont des implémentations différentes des mêmes choses. C'est une chienne à gérer, pour le moins. Mais c'est la prémisse, que cela vous plaise ou non.

Peut-être que vous travaillez sur des projets à grande échelle qui ont besoin de performance pour que vous puissiez vraiment voir la différence entre 850 000 (trait de soulignement) et 2 500 000 itérations (lodash) sur une liste par seconde maintenant!

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'ont jamais été résolus ou provoqués par Underscore ou Lo-Dash. Et à moins que je n'obtienne les vraies différences dans l'implémentation et la performance (nous parlons du C ++ en ce moment) de disons une boucle sur un itérable (objet ou tableau, clairsemé ou pas!), Je ne suis pas dérangé par aucun revendications fondées sur les résultats d'une plate-forme de référence est déjà opiniâtre.

Il suffit d'une seule mise à jour de Rhino pour que ses implémentations de méthodes Array soient en feu, de telle sorte que pas une seule méthode de boucle médiévale ne fonctionne mieux et que le prêtre puisse se disputer le simple fait que un brusque tableau méthodes dans FF sont beaucoup plus rapides que son brainfuck opiniâtre. Man, vous ne pouvez pas tricher votre environnement d'exécution en trompant votre environnement d'exécution! Pensez-y lors de la promotion ...

votre ceinture utilitaire

... la prochaine fois.

Donc, pour le garder pertinent:

  • Utilisez Underscore si vous êtes dans la commodité sans sacrifier natif natif.
  • Utilisez Lo-Dash si vous êtes à l'aise et aimez son catalogue de fonctionnalités étendu (copie profonde, etc.) et si vous avez désespérément besoin de performances instantanées et surtout ne vous inquiétez pas de trouver une alternative dès que l'API native éclipse workaurounds opiniâtres. Ce qui va arriver bientôt. Période.
  • Il y a même une troisième solution. DIY! Connaissez vos environnements. Connaître les incohérences Lisez leur (John-David'le sable Jeremy(s) code. N'utilisez pas ceci ou cela sans être capable d'expliquer pourquoi une couche de cohérence / compatibilité est vraiment nécessaire et améliore votre flux de travail ou améliore les performances de votre application. Il est très probable que vos exigences sont satisfaites avec un polyfill simple que vous êtes parfaitement capable d'écrire vous-même. Les deux bibliothèques sont tout simplement vanille avec un peu de sucre. Ils se battent tous les deux pour savoir qui sert la meilleure tarte. Mais croyez-moi, à la fin les deux cuisinent seulement avec de l'eau. Il n'y a pas de Dieu Vanille alors il ne peut pas y avoir de pape Vanille, n'est-ce pas?

Choisissez l'approche qui correspond le mieux à vos besoins. Comme d'habitude. Je préférerais des retombées sur des implémentations réelles plutôt que sur des cheats d'exécution à tout moment, mais même cela semble être une question de goût de nos jours. S'en tenir à des ressources de qualité comme http://developer.mozilla.com et http://caniuse.com et tout ira bien.


43
2017-09-11 21:27



Je suis d'accord avec la plupart des choses dites ici mais je veux juste souligner un argument en faveur de underscore.js: la taille de la bibliothèque.

Spécialement dans le cas où vous développez une application ou un site Web qui a l'intention d'être utilisé principalement sur des appareils mobiles, la taille de l'ensemble résultant et l'effet sur le démarrage ou le temps de téléchargement peuvent avoir un rôle important.

A 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

14
2018-04-26 14:20



Je ne sais pas si c'est ce que OP voulait dire, 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 de underscore à lodash.

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

  • _.flatten en underscore est profond par défaut et vous devez passer true en second argument pour le rendre peu profond. En lodash, il est peu profond par défaut et passe true car le second argument le rend profond! :)
  • _.last en underscore accepte un second argument qui indique combien d'éléments vous voulez. Dans lodash il n'y a pas une telle option. Vous pouvez émuler ceci avec .slice
  • _.first (même problème)
  • _.template dans le trait de soulignement peut être utilisé de plusieurs façons, dont l'un est de fournir la chaîne de modèle et de données et d'obtenir HTML retour (ou du moins c'est comme ça que ça a fonctionné il y a quelque temps). Dans lodash vous recevez une fonction que vous devez ensuite nourrir avec les données.
  • _(something).map(foo) travaille en trait de soulignement, mais dans lodash je devais le réécrire _.map(something,foo). Peut-être que c'était juste un TypeScript-problème

9
2018-03-25 12:16



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

Dernier article comparant les deux par Ben McCormick:

  1. L'API de Lo-Dash est un surensemble de Underscore.

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

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

  4. Qu'a ajouté Lo-Dash?

    • Améliorations de l'utilisabilité
    • Fonctionnalité supplémentaire
    • Gains de performance
    • Syntaxes raccourcies pour chaîner
    • Constructions personnalisées pour utiliser uniquement ce dont vous avez besoin
    • Versioning sémantique et couverture de code à 100%

8
2017-12-07 12:19