Różnice między lodash a podkreśleniem [zamknięte]

1602

Dlaczego ktoś wolałby bibliotekę narzędziową lodash.js lub underscore.js od drugiej?

Wydaje się, że Lodash zastępuje podkreślenie, które jest już dłuższe.

Myślę, że oba są genialne, ale nie wiem wystarczająco dużo o tym, jak działają, aby dokonać wykształconego porównania, i chciałbym dowiedzieć się więcej o różnicach.

Brian M. Hunt
źródło
2
Możesz rzucić okiem na niektóre z ekranów dotyczących lodash, do których prowadzą linki na stronie github. Osobiście korzystam z underscore.js, ale więcej, ponieważ to od tego zacząłem i, jak mówisz, jest już dłużej.
Jack
26
lodashi underscoresą teraz w wątku scalającym
zangw

Odpowiedzi:

2022

Stworzyłem Lo-Dash, aby zapewnić bardziej spójną obsługę iteracji w różnych środowiskach dla tablic, ciągów, obiektów i argumentsobiektów 1 . Od tego czasu stał się nadzbiorem Underscore, zapewniając bardziej spójne zachowanie API, więcej funkcji (takich jak wsparcie AMD, głęboki klon i głębokie scalanie), dokładniejszą dokumentację i testy jednostkowe (testy, które działają w Node, Ringo, Rhino, Narwhal, PhantomJS i przeglądarki), lepsza ogólna wydajność i optymalizacja dla dużych tablic / iteracji obiektów oraz większa elastyczność dzięki niestandardowym kompilacjom i narzędziom do wstępnej kompilacji szablonów.

Ponieważ Lo-Dash jest aktualizowana częściej niż podkreślenia, o lodash underscorebuild jest do zapewnienia kompatybilności z najnowszą wersją stabilną od podkreślenia.

W pewnym momencie dostałem nawet dostęp push do Underscore, częściowo dlatego, że Lo-Dash jest odpowiedzialny za podniesienie ponad 30 problemów; poprawki błędów lądowania, nowe funkcje i ulepszenia w Underscore v1.4.x +.

Ponadto istnieją co najmniej 3 płyty kotłowe szkieletowe, które domyślnie zawierają Lo-Dash, a Lo-Dash jest teraz wspomniany w oficjalnej dokumentacji Backbone .

Zapoznaj się z postem Kit Cambridge, powiedz „Hello” Lo-Dash , aby dowiedzieć się więcej o różnicach między Lo-Dash a Underscore.

Przypisy:

  1. Podkreślenie ma niespójną obsługę tablic, ciągów, obiektów i argumentsobiektów. W nowszych przeglądarkach metody Underscore ignorują dziury w tablicach , metody „Objects” iterują argumentsobiekty, łańcuchy są traktowane jak tablice, a metody poprawnie iterują funkcje (ignorując ich właściwość „prototypową”) i obiekty (iterujące właściwości shadow, takie jak „toString” i „valueOf”), podczas gdy w starszych przeglądarkach nie. Ponadto metody podkreślania, takie jak _.clonezachowanie dziur w tablicach, podczas gdy inne _.flattennie.
John-David Dalton
źródło
174
@Brian - Podczas opracowywania Lo-Dash nadal zadawałem pytanie „Co ktoś może wskazać w Lo-Dash jako negatywny w porównaniu do podkreślenia?” a następnie adresuj je. Dlatego rozbudowałem dokumentację, dodałem niestandardowe kompilacje i sprawiłem, że źródło jest bardziej czytelne.
John-David Dalton
10
Bardzo kusi mnie, aby opublikować kilka testów porównawczych, ale może to być nudne. Wystarczy powiedzieć, że każdy test, który przeprowadziłem, udowodnił, że Lo-Dash jest szybszy ( w wielu przypadkach DUŻO szybszy) niż podkreślenie.
Wil Moore III
186
Uwielbiam lo-dash i używam go, więc proszę, nie myśl, że walę, ale dlaczego nie przyczynić się do podkreślenia zamiast tworzenia nowej biblioteki?
Xananax,
133
@Xananax - sprawdź wątek komentarzy: github.com/jashkenas/underscore/commit/… - może to odpowiedzieć na to pytanie.
Rob Grant,
41
Czy podjęto próbę scalenia lodash z powrotem w podkreślenie?
latarnia
186

Lo-Dash został zainspirowany podkreśleniem, ale obecnie jest doskonałym rozwiązaniem. Możesz tworzyć własne kompilacje , mieć wyższą wydajność , wspierać AMD i mieć wspaniałe dodatkowe funkcje . Sprawdź testy porównawcze Lo-Dash vs. Underscore na jsperf i .. ten niesamowity post o lo-dash :

Jedną z najbardziej przydatnych funkcji podczas pracy ze zbiorami jest skrócona składnia:

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

(wzięte z dokumentów Lodash )

neiker
źródło
1
Link do bloga Kit Cambridge jest bardzo pouczający.
Brian M. Hunt
Myślę, że to źle (przykład wyrywanie). Począwszy od ostatniej aktualizacji 1.8.3, możesz używać skubania w taki sam sposób, jak lodash. zresztą w poprzednich wersjach nie sądzę, że podkreślenie ujawniłoby funkcję, która jest tą samą mapą (twój przykład podkreślenia wygląda jak funkcja mapy)
alexserver
7
filterfunkcja w podkreśleniu z 2012 github.com/jashkenas/underscore/issues/648 (nazywa się where)
Muhammad Hewedy
Otrzymuję błąd 500 w linku do testu porównawczego Lo-Dash vs. Underscore
Hylle
86

Jeśli podobnie jak ja spodziewałeś się listy różnic w użyciu między podkreślnikiem a lodash, istnieje przewodnik dotyczący migracji z podkreślenia do lodash .

Oto jego obecny stan dla potomności:

  • Podkreślenie _.anyto Lodash_.some
  • Podkreślenie _.allto Lodash_.every
  • Podkreślenie _.composeto Lodash_.flowRight
  • Podkreślenie _.containsto Lodash_.includes
  • Podkreślenie _.eachnie pozwala na wyjście przez powrótfalse
  • Podkreślenie _.findWhereto Lodash_.find
  • Podkreślać _.flatten jest domyślnie głębokie, natomiast Lodash jest płytkie
  • Podkreślenie _.groupByobsługuje iterację, której parametry są przekazywane (value, index, originalArray), natomiast w Lodash iterat_.groupBy przepuszcza tylko jeden parametr: (value).
  • Podkreślać _.indexOf z 3 parametrem undefinedjest Lodash_.indexOf
  • Podkreślać _.indexOf z 3 parametrem truejest Lodash_.sortedIndexOf
  • Podkreślać _.indexByto Lodash_.keyBy
  • Podkreślać _.invoketo Lodash_.invokeMap
  • Podkreślać _.mapObjectto Lodash_.mapValues
  • Podkreślać _.max łączy Lodash _.maxi_.maxBy
  • Podkreślenie _.minłączy Lodash_.mini_.minBy
  • Podkreślenie _.samplełączy Lodash_.samplei_.sampleSize
  • Podkreślenie _.objectłączy Lodash_.fromPairs i_.zipObject
  • Podkreślać _.omit predykatu jest Lodash_.omitBy
  • Podkreślać _.pairsto Lodash_.toPairs
  • Podkreślać _.pick predykatu jest Lodash_.pickBy
  • Podkreślać _.pluckto Lodash_.map
  • Podkreślenie _.sortedIndexłączy Lodash_.sortedIndexi_.sortedIndexOf
  • Podkreślenie _.uniqprzeziteratee jest Lodash_.uniqBy
  • Podkreślać _.whereto Lodash_.filter
  • Podkreślenie _.isFinitenie jest wyrównane Number.isFinite
    (np. _.isFinite('1')Zwraca truew Podkreśleniu, alefalse w Lodash)
  • _.matchesSkrót podkreślenia nie obsługuje głębokich porównań
    (np_.filter(objects, { 'a': { 'b': 'c' } }) )
  • Podkreślenie ≥ 1.7 i _.templateskładnia Lodash jest
    _.template(string, option)(data)
  • Skrytki Lodash _.memoizeMapjak obiekty
  • Lodash nie popiera contextargumentu dla wielu metod na korzyść_.bind
  • Lodash obsługuje niejawne tworzenie łańcuchów , leniwe tworzenie łańcuchów i skrótów
  • Lodash podzielić jego przeciążony _.head, _.last, _.rest, i _.initialsię do
    _.take, _.takeRight, _.drop, i _.dropRight
    (czyli _.head(array, 2)w Podkreślenie jest _.take(array, 2)w Lodash)
Iest
źródło
1
Sam napotkałem te problemy podczas migracji i utrzymuję dokumentację krzyżową między WIP . Mam nadzieję, że jest to pomocne również dla innych ludzi!
luxon
60

Oprócz odpowiedzi Johna i czytania o lodash (które do tej pory uważałem za „ja też”, aby podkreślić), a także sprawdzanie wydajności, czytanie kodu źródłowego i postów na blogu , kilka punktów, które sprawiają, że lodash znacznie lepsze niż podkreślenia są:

  1. Nie chodzi o prędkość, ponieważ chodzi o spójność prędkości (?)

    Jeśli spojrzysz na kod źródłowy podkreślenia, zobaczysz w pierwszych kilku wierszach, że podkreślenie opiera się na natywnych implementacjach wielu funkcji. Chociaż w idealnym świecie byłoby to lepsze podejście, jeśli spojrzysz na niektóre linki perf podane w tych slajdach , nietrudno wyciągnąć wniosek, że jakość tych „natywnych implementacji” różni się znacznie w przeglądarce - do przeglądarki. Firefox jest cholernie szybki w niektórych funkcjach, a w niektórych dominuje Chrome. (Wyobrażam sobie, że byłyby scenariusze, w których dominowałby również IE). Uważam, że lepiej jest preferować kod, którego wydajność jest bardziej spójna w różnych przeglądarkach.

    Przeczytaj wcześniej post na blogu i zamiast w to wierzyć, oceniaj sam, przeprowadzając testy porównawcze . Jestem teraz oszołomiony, widząc lodash wykonujący 100-150% szybciej niż podkreślenie nawet w prostych , natywnych funkcjach, takich jak Array.everyChrome!

  2. te dodatki w lodash są również bardzo użyteczne.

  3. Jeśli chodzi o wysoko oceniany komentarz Xananax sugerujący wkład w kod podkreślenia: Zawsze lepiej jest mieć DOBRE współzawodnictwo, nie tylko utrzymuje innowacyjność, ale także prowadzi cię do utrzymania siebie (lub biblioteki) w dobrej formie.

Oto lista różnic między lodash, a jego kompilacja podkreślenia zastępuje twoje projekty podkreślania.

kumarharsh
źródło
6
W którym przypadku „spójność prędkości” jest wartością? Powiedzmy, że mam metodę, która ma prędkość 100% w FF i IE, a natywna implementacja miałaby prędkość 80% w IE i 120% w FF (lub odwrotnie). Powiedziałbym wtedy, że dobrze byłoby użyć implementacji natywnej w FF i własnej implementacji w IE. Nie wyobrażam sobie żadnego przypadku, w którym powiedziałbym: zwolnijmy FF tylko dlatego, że mamy tam taką samą prędkość jak w IE. Rozmiar kodu i łatwość konserwacji lub średnie spowolnienie we wszystkich przeglądarkach byłyby argumentami, ale spójność szybkości?
stofl
2
Miałem na myśli „konsekwentnie większą prędkość”
kumarharsh
1
Co z różnicą wielkości? Załóżmy, że tworzysz niestandardową kompilację z lodash, która ma dokładnie taką samą funkcjonalność jak podkreślenie? Czy jest między nimi duża różnica? Sądzę, że ponowna implementacja zwiększa wagę witryny.
F Lekschas,
5
Jestem skłonny wrócić do natywnej implementacji przeglądarki po prostu dlatego, że w większości przypadków ma ona akceptowalną wydajność i może się poprawiać dzięki aktualizacjom przeglądarki bez obaw o aktualizację biblioteki.
orad
3
@KumarHarsh Może nie wyraziłem tego dobrze. Chodzi mi o to, że mam skłonność do korzystania z biblioteki, która wewnętrznie korzysta z funkcji natywnych, jeśli są one dostępne, zamiast zawsze preferować własną implementację.
orad
42

Jest rok 2014 i kilka lat za późno. Mimo to myślę, że moja uwaga dotyczy:

IMHO ta dyskusja dość mocno wyleciała z proporcji. Cytując wyżej wspomniany post na blogu :

Większość bibliotek narzędzi JavaScript, takich jak Underscore, Valentine i wu, korzysta z „podwójnego podejścia natywnego”. Takie podejście preferuje natywne implementacje, wracając do waniliowego JavaScript tylko wtedy, gdy natywny odpowiednik nie jest obsługiwany. Ale jsPerf ujawnił interesujący trend: najskuteczniejszym sposobem na iterację tablicy lub kolekcji podobnej do tablicy jest całkowite uniknięcie implementacji natywnych, zamiast tego wybór prostych pętli.

Jakby „proste pętle” i „waniliowe Javascript” były bardziej natywne niż implementacje metod Array lub Object. Jezu ...

Z pewnością byłoby miło mieć jedno źródło prawdy, ale tak nie jest. Nawet jeśli powiedziano ci inaczej, nie ma Boga Waniliowego, moja droga. Przepraszam. Jedynym prawdziwym założeniem jest to, że wszyscy piszemy kod JavaScript, który ma na celu osiąganie dobrych wyników we wszystkich głównych przeglądarkach, wiedząc, że wszystkie mają różne implementacje tych samych rzeczy. To dziwka, z którą trzeba sobie poradzić, delikatnie mówiąc. Ale to jest przesłanka, czy ci się to podoba, czy nie.

Być może wszyscy pracują nad projektami na dużą skalę, które wymagają twitterowej wydajności, aby naprawdę zobaczyć różnicę między 850 000 (podkreślenie) a 2 500 000 (lodash) iteracji na liście na sekundę teraz!

Ja nie jestem. To znaczy pracowałem nad projektami, w których musiałem zająć się problemami z wydajnością, ale nigdy nie zostały one rozwiązane ani spowodowane ani przez podkreślenie, ani przez Lo-Dash. I dopóki nie zrozumiem prawdziwych różnic w implementacji i wydajności (mówimy teraz o C ++), powiedzmy, że istnieje pętla nad iterowalnym (obiekt lub tablica, rzadka lub nie!), Raczej nie przeszkadza mi żadna roszczenia oparte na wynikach platformy porównawczej, która jest już opiniowana .

Potrzebuje tylko jednej aktualizacji, powiedzmy Rhino, aby podpalić implementacje metody Array w taki sposób, aby żadna „średniowieczna metoda pętli nie działała lepiej i na zawsze, a kapłan nie może się kłócić o prosty fakt, że wszystkie nagłe metody tablicowe w FF są znacznie szybsze niż jego / jej zdaniem pieprzony mózg. Człowieku, nie możesz oszukiwać środowiska wykonawczego, oszukując środowisko wykonawcze! Pomyśl o tym, promując ...

twój pasek narzędzi

... następnym razem.

Aby zachować aktualność:

  • Użyj Podkreślenia, jeśli masz wygodę bez poświęcania natywnego ish.
  • Użyj Lo-Dash, jeśli podoba ci się wygoda i lubisz jego rozszerzony katalog funkcji (głębokie kopiowanie itp.) I jeśli rozpaczliwie potrzebujesz natychmiastowej wydajności, a co najważniejsze, nie przejmuj się alternatywą, gdy tylko natywny interfejs API przestanie być widoczny. opiniotwórcze prace. Co się stanie wkrótce. Kropka.
  • Istnieje nawet trzecie rozwiązanie. MAJSTERKOWANIE! Poznaj swoje środowiska. Wiedzieć o niespójnościach. Przeczytaj ich kod ( John-David i Jeremy ). Nie używaj tego ani tamtego, nie będąc w stanie wyjaśnić, dlaczego warstwa spójności / zgodności jest naprawdę potrzebna i poprawia przepływ pracy lub poprawia wydajność aplikacji. Jest bardzo prawdopodobne, że twoje wymagania są spełnione przez prosty wypełniacz, który jesteś w stanie sam napisać. Obie biblioteki to zwykła wanilia z odrobiną cukru. Oboje po prostu walczą o to, kto podaje najsłodsze ciasto . Ale uwierz mi, w końcu oboje gotują tylko z wodą. Nie ma boga wanilii, więc nie może być papieża wanilii, prawda?

Wybierz podejście, które najbardziej odpowiada Twoim potrzebom. Jak zwykle. Wolę w każdej chwili wycofywanie się z rzeczywistych wdrożeń niż wyrażanie oszustw w czasie wykonywania, ale nawet to wydaje się obecnie kwestią gustu. Trzymaj się wysokiej jakości zasobów, takich jak http://developer.mozilla.com i http://caniuse.com, a wszystko będzie dobrze.

Lukas Bünger
źródło
Dzięki za wysłanie Lukasa. Czy wbudowane elementy można dalej optymalizować? Stwierdziłem, że mają ograniczenia narzucone przez standardy, które uniemożliwiają im optymalizacje porównywalne z bibliotekami, ale nie znam szczegółów od razu ani tego, czy to było, czy pozostaje prawdą.
Brian M. Hunt
np. „Optymalizując dla przypadku użycia 99%, metody fast.js mogą być nawet 5 razy szybsze niż ich natywne odpowiedniki”. - github.com/codemix/fast.js
Brian M. Hunt
1
Cześć Brian, przepraszam, jeśli to było mylące, nie chciałem powiedzieć, że te biblioteki nie są dużo szybsze niż ich natywne odpowiedniki. Jeśli desperacko potrzebujesz wydajności w tej chwili , zapewne lepiej skorzystasz z zestawu narzędzi takiego jak LoDash lub fast.js, ponieważ zapewniają one szybsze implementacje standardowych metod. Ale jeśli zdecydujesz się użyć biblioteki, która nie opiera się na metodach natywnych, możesz po prostu przegapić przyszłe optymalizacje wydajności wbudowanych. Przeglądarki ostatecznie ewoluują.
Lukas Bünger
4
„Producentom” przeglądarek trudno jest zachować zgodność ze standardami przeglądarek, a tym bardziej wydajność. Większość przyrostów wydajności w natywnych implementacjach wynika z szybszego sprzętu. „Natywne implementacje nadrobią zaległości”, istnieją już od lat. Lata = wieczność w Internecie. JEŻELI natywne implementacje kiedykolwiek nadrobią zaległości, biblioteki zostaną zaktualizowane, aby z nich korzystać. To jest fajne w open source. Jeśli programista aplikacji nie zaktualizuje się do najnowszej biblioteki, jego aplikacja nie zwolni nagle, po prostu nie przyspieszy.
Andrew Steitz,
2
... ale gdybyś ich zapytał Array.from, prawdopodobnie nawet nie wiedzieliby, co powinien zrobić. Ludzie z „paskiem użytkowym” JS wydają się tak bardzo zainteresowani promowaniem swoich tak bardzo genialnych obejść, że zapominają, że robiąc to, faktycznie osłabiają proces standaryzacji. Brak potrzebnych funkcji nie powoduje presji na „producentów” przeglądarki. Ciekawostka: 2 z 4 głównych przeglądarek są oparte na projektach typu open source ( 1 , 2 ).
Lukas Bünger,
20

Zgadzam się z większością rzeczy tutaj powiedzianych, ale chcę jedynie wskazać argument na korzyść underscore.js: rozmiar biblioteki.

Szczególnie w przypadku tworzenia aplikacji lub strony internetowej, które mają być używane głównie na urządzeniach mobilnych, rozmiar wynikowego pakietu i wpływ na czas uruchamiania lub pobierania mogą odgrywać ważną rolę.

Dla porównania, te rozmiary to te, które zauważyłem w Eksploratorze map źródłowych po uruchomieniu serwera jonowego:

lodash: 523kB
underscore.js: 51.6kb

zredagowano lut 2020 :

można użyć BundlePhobia, aby sprawdzić aktualny rozmiar Lo-Dash i Underscore

David Dal Busco
źródło
1
Dzięki Peter, warto tutaj zwrócić uwagę. W innych miejscach jest więcej dyskusji, w tym: gist.github.com/alekseykulikov/5f4a6ca69e7b4ebed726 . (Ta odpowiedź może zostać poprawiona poprzez połączenie niektórych innych dyskusji i zacytowanie odpowiednich fragmentów). Różnicę w wielkości można zmniejszyć, wybierając podsekcje lodash plus lodash wstrząsający drzewem. 🕷
Brian M. Hunt
Dzięki @ BrianM.Hunt za twoją odpowiedź, nie wiedziałem, że można dołączyć podsekcje lodash, zobaczę. Ostatnio z Ionic-native, Ionic obrał taką samą ścieżkę dla swoich rodzimych bibliotek, warto zauważyć, że bardziej martwi się o rozmiar aplikacji
David Dal Busco
1
zastanawiam się skąd masz 523kB? lodash.com twierdzi, że jest skompresowany tylko w 24kB. pobrano tylko 74kB
Martian2049,
1
mój post został opublikowany w kwietniu 2017 r., jak powiedziałem w moim komentarzu,source-map-explorer after running ionic serve
David Dal Busco
5
W marcu 2018 r. - lodash.min.js wynosi 72,5 kB, a podkreślenie-min.js wynosi 16,4 kB
Połącz
10

Nie jestem pewien, czy to właśnie oznaczało OP, ale natknąłem się na to pytanie, ponieważ szukałem listy problemów, o których muszę pamiętać przy migracji z podkreślenia do lodash.

Byłbym bardzo wdzięczny, gdyby ktoś opublikował artykuł z pełną listą takich różnic. Zacznę od rzeczy, których nauczyłem się na własnej skórze (tj. Rzeczy, które spowodowały, że mój kod eksplodował podczas produkcji: /):

  • _.flattenw podkreśleniu jest domyślnie głęboki i musisz przekazać true jako drugi argument, aby był płytki. W lodash jest on domyślnie płytki i przekazanie go jako drugiego argumentu spowoduje, że będzie on głęboki! :)
  • _.lastw podkreśleniu akceptuje drugi argument, który mówi, ile elementów chcesz. W lodashnie ma takiej opcji. Możesz to naśladować.slice
  • _.first (ten sam problem)
  • _.templatew podkreśleniu można używać na wiele sposobów, jednym z nich jest dostarczenie ciągu szablonu i danych oraz HTMLpowrót (lub przynajmniej tak to działało jakiś czas temu). W lodashotrzymujesz funkcję, którą powinieneś następnie karmić danymi.
  • _(something).map(foo)działa w podkreśleniu, ale w lodash musiałem go przepisać _.map(something,foo). Być może była to tylko TypeScriptkwestia
qbolec
źródło
4
W lodash łączenie łańcuchowe przechodzi przez leniwy iterator i wymaga jak i punktu końcowego _(something).map(foo).value().
Brian M. Hunt
To wszystko może Cię uderzyć, jeśli użyjesz Backbone Collection, które proxy wywołuje wywołania tych bibliotek - na przykład collection.first (5) nie da ci pierwszych 5 elementów, a raczej pierwszy :)
qbolec
8

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

Najnowszy artykuł porównujący dwa autorstwa Bena McCormicka:

  1. Interfejs API Lo-Dash jest nadzbiorem Underscore.

  2. Pod maską [Lo-Dash] został całkowicie przepisany.

  3. Lo-Dash zdecydowanie nie jest wolniejszy niż podkreślenie.

  4. Co dodano do Lo-Dash?

    • Ulepszenia użyteczności
    • Dodatkowa funkcjonalność
    • Zyski wydajności
    • Skrócone składnie łańcuchów
    • Kompilacje niestandardowe używają tylko tego, czego potrzebujesz
    • Wersje semantyczne i 100% pokrycia kodu
pilaw
źródło
6

Właśnie znalazłem jedną różnicę, która okazała się dla mnie ważna. Wersja Lodash, _.extend()która nie jest kompatybilna z podkreśleniem, nie kopiuje właściwości lub metod zdefiniowanych na poziomie klasy.

Stworzyłem test Jasmine w CoffeeScript, który pokazuje to:

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

Na szczęście lodash.underscore.jszachowuje zachowanie Underscore polegające na kopiowaniu wszystkiego, co w mojej sytuacji było zachowaniem pożądanym.

Craig Walker
źródło
4

lodash ma _.mapValues()to samo co undrescore _.mapObject().

artknight
źródło
0

W przeważającej części podkreślenie stanowi podzbiór lodash. Czasami, podobnie jak obecnie podkreślenie, będzie miało fajne małe funkcje, które lodash nie ma jak mapObject. Ten zaoszczędził mi dużo czasu na rozwój mojego projektu.

rashadb
źródło
w tej chwili mamy _.mapWartości
crapthings
@crapthings - w czasie tego postu wiedziałem o mayValues ​​i mapKeys, ale to nie to samo co mapObject. Być może istnieją przypadki nałożenia jednej na drugą, ale mapObject jest funkcją samą w sobie.
rashadb
0

Są do siebie bardzo podobne, a Lodash przejmuje ...

Obie są biblioteką narzędzi, która zabiera świat narzędzi w JavaScript ...

Wygląda na to, że Lodash jest teraz regularnie aktualizowany, więc częściej wykorzystywany w najnowszych projektach ...

Również Lodash wydaje się lżejszy przez kilka KB ...

Oba mają dobre API i dokumentację, ale myślę, że Lodash jest lepszy ...

Oto zrzut ekranu dla każdego dokumentu w celu uzyskania pierwszej wartości tablicy ...

podkreślać:

podkreślać

lodash: lodash

Ponieważ od czasu do czasu rzeczy mogą się aktualizować, po prostu sprawdź ich stronę internetową ...

lodash

podkreślać

Alireza
źródło