[underscore.js] lodash와 밑줄의 차이점 [닫힘]

Program / 글쓴이

왜 누군가가 lodash.js 또는 underscore.js 유틸리티 라이브러리를 선호 합니까?

Lodash는 밑줄을 대체하는 것으로 보이며 후자는 더 오래되었습니다.

나는 둘 다 훌륭하다고 생각하지만, 그들이 교육 비교를하기 위해 어떻게 작동하는지에 대해 충분히 알지 못하며 차이점에 대해 더 알고 싶습니다.

답변

배열, 문자열, 객체 및 arguments객체에 대해보다 일관된 교차 환경 반복 지원을 제공하기 위해 Lo-Dash를 만들었습니다 1 . 이후 Underscore의 상위 세트가되어보다 일관된 API 동작, 더 많은 기능 (AMD 지원, 딥 클론 및 딥 병합 등),보다 철저한 문서 및 단위 테스트 (노드, 링고, 코뿔소, 나르 왈, PhantomJS에서 실행되는 테스트)를 제공합니다. , 브라우저), 대규모 배열 / 객체 반복에 대한 전반적인 성능 및 최적화 향상, 사용자 지정 빌드 및 템플릿 사전 컴파일 유틸리티를 통한 유연성 향상 .

Lo-Dash는 Underscore보다 더 자주 업데이트 되므로 최신 안정적인 Underscore 버전과 호환되도록 lodash underscore빌드 가 제공 됩니다.

어느 시점 에서 LosDash가 30 개 이상의 문제를 제기 할 책임이 있기 때문에 Underscore에 대한 푸시 액세스 권한 도 부여되었습니다 . Underscore v1.4.x +의 랜딩 버그 수정, 새로운 기능 및 성능 향상.

또한 기본적으로 Lo-Dash를 포함하는 최소 3 개의 Backbone 상용구가 있으며 이제 Lo-Dash가 Backbone의 공식 문서에 언급되어 있습니다 .

Lo-Dash와 Underscore의 차이점에 대한 자세한 내용은 Kit Cambridge의 Post “Hello”to Lo-Dash 를 참조하십시오.

각주 :

  1. 밑줄은 배열, 문자열, 객체 및 arguments객체 를 일관되지 않게 지원 합니다. 최신 브라우저에서 Underscore 메소드는 배열의 구멍을 무시 하고 “Objects”메소드는 arguments객체를 반복 하고 문자열은 배열과 같이 취급되며, 메소드는 함수 ( “prototype”속성 무시)와 객체 ( “toString”과 같은 그림자 속성 반복)를 올바르게 반복합니다. “valueOf”), 이전 브라우저에서는 그렇지 않습니다. 또한 밑줄 방법 _.clone은 배열에 구멍을 유지하는 반면 다른 방법은 _.flatten그렇지 않습니다.

답변

Lo-Dash는 밑줄에서 영감을 얻었지만 요즘에는 탁월한 솔루션입니다. 당신은 할 수 있습니다 사용자 정의 빌드 이, 더 높은 성능을 , AMD를 지원하고있는 훌륭한 추가 기능 . 이 확인 밑줄 벤치 마크 대비 소호 – 대시를 ..이 jsperf에와 보라 – 대시에 대한 멋진 게시물 :

컬렉션으로 작업 할 때 가장 유용한 기능 중 하나는 속기 구문입니다.

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

( lodash 문서 에서 가져온 )

답변

저와 같이 밑줄과 lodash의 사용법 차이 목록을 기대하고 있다면 밑줄에서 lodash로 마이그레이션하기위한 안내서가 있습니다.

후손에 대한 현재 상태는 다음과 같습니다.

  • 밑줄 _.any은 Lodash입니다_.some
  • 밑줄 _.all은 Lodash입니다_.every
  • 밑줄 _.compose은 Lodash입니다_.flowRight
  • 밑줄 _.contains은 Lodash입니다_.includes
  • 밑줄 _.each은 반환하여 종료를 허용하지 않습니다false
  • 밑줄 _.findWhere은 Lodash입니다_.find
  • _.flatten기본적으로 밑줄 은 깊고 Lodash는 얕습니다.
  • Underscore _.groupBy는 매개 변수가 전달 된 iteratee를 지원하는 (value, index, originalArray)반면 Lodash에서는 iteratee _.groupBy가 단일 매개 변수 만 전달 (value)됩니다.
  • _.indexOf3 번째 매개 변수를 가진 밑줄 undefined은 Lodash입니다_.indexOf
  • _.indexOf3 번째 매개 변수를 가진 밑줄 true은 Lodash입니다_.sortedIndexOf
  • 밑줄 _.indexBy은 Lodash입니다_.keyBy
  • 밑줄 _.invoke은 Lodash입니다_.invokeMap
  • 밑줄 _.mapObject은 Lodash입니다_.mapValues
  • 밑줄 _.max은 Lodash _.max와_.maxBy
  • 밑줄 _.min은 Lodash _.min와_.minBy
  • 밑줄 _.sample은 Lodash _.sample와_.sampleSize
  • 밑줄 _.object은 Lodash _.fromPairs와_.zipObject
  • _.omit술어에 의한 밑줄 은 Lodash입니다._.omitBy
  • 밑줄 _.pairs은 Lodash입니다_.toPairs
  • _.pick술어에 의한 밑줄 은 Lodash입니다._.pickBy
  • 밑줄 _.pluck은 Lodash입니다_.map
  • 밑줄 _.sortedIndex은 Lodash _.sortedIndex와_.sortedIndexOf
  • 밑줄 _.uniq로는 iterateeLodash입니다_.uniqBy
  • 밑줄 _.where은 Lodash입니다_.filter
  • 밑줄 _.isFinite이 정렬되지 않습니다 Number.isFinite
    (예 : 밑줄 에서 Lodash로 _.isFinite('1')반환 )truefalse
  • 밑줄 _.matches깊은 비교를 지원하지 않습니다 속기
    (예 _.filter(objects, { 'a': { 'b': 'c' } }))
  • 밑줄 ≥ 1.7 & Lodash _.template구문은
    _.template(string, option)(data)
  • Lodash _.memoize캐시는 Map객체와 같습니다
  • Lodash는 context많은 방법에 찬성론을 지지하지 않습니다._.bind
  • Lodash는 암시 적 체인 , 지연 체인 및 바로 가기 융합을 지원합니다
  • Lodash는 오버로드 분할 _.head, _.last, _.rest, _.initial속으로
    _.take, _.takeRight, _.drop, _.dropRight
    (즉, _.head(array, 2)밑줄이에 _.take(array, 2)Lodash에서)

답변

John의 답변 외에도 lodash (지금까지는 밑줄로 “나쁜”것으로 간주 됨)를 읽고 성능 테스트를보고 소스 코드를 읽고 블로그 게시물 을 읽습니다. 밑줄보다 훨씬 우수한 것은 다음과 같습니다.

  1. 속도의 일관성 에 관한 것이기 때문에 속도에 관한 것이 아닙니다.

    밑줄의 소스 코드를 살펴보면 처음 몇 줄에서 밑줄이 많은 함수의 기본 구현을 대체하는 것을 볼 수 있습니다. 이상적인 세계에서는 이것이 더 나은 접근 방법 일 것입니다. 이 슬라이드에 제공된 성능 링크 중 일부를 살펴보면 ‘기본 구현’의 품질이 브라우저마다 크게 다르다는 결론을 내리는 것은 어렵지 않습니다. 브라우저로. Firefox는 일부 기능에서 빠르며 일부 Chrome에서는 우세합니다. (IE가 지배 할 시나리오가있을 것이라고 생각합니다). 브라우저에서 성능 이 더 일관된 코드를 선호하는 것이 좋습니다 .

    앞서 블로그 게시물을 읽은 후 블로그를 믿지 말고 벤치 마크 를 실행하여 스스로 판단하십시오 . 난에 100~150% 빠른 밑줄보다 더 수행하는 lodash보고, 지금 기절하고 간단한 , 원시 등의 기능 Array.every크롬을!

  2. lodash 의 엑스트라 도 매우 유용합니다.

  3. Xananax의 높은 평가 의견은 밑줄 코드에 대한 기여를 제안합니다. GOOD 경쟁 을하는 것이 항상 낫습니다. 혁신을 계속 유지할뿐만 아니라 자신 (또는 라이브러리)을 좋은 모양으로 유지하도록 유도합니다.

lodash 의 차이점 목록은 다음과 같습니다. 밑줄 빌드는 밑줄 프로젝트를 대체하는 대체물입니다.

답변

이것은 2014 년이며 몇 년이 너무 늦었습니다. 여전히 내 요점은 다음과 같습니다.

IMHO이 토론은 꽤 많은 비율에서 나왔습니다. 위에서 언급 한 블로그 게시물 인용 :

Underscore, Valentine 및 wu와 같은 대부분의 JavaScript 유틸리티 라이브러리는 “native-first dual approach”에 의존합니다. 이 접근 방식은 기본 구현을 선호하며 기본 동등 기능이 지원되지 않는 경우에만 바닐라 JavaScript로 돌아갑니다. 그러나 jsPerf는 흥미로운 경향을 보여주었습니다. 배열 또는 배열과 같은 컬렉션을 반복하는 가장 효율적인 방법은 간단한 루프를 선택하여 기본 구현을 완전히 피하는 것입니다.

마치 “단순 루프”와 “vanilla Javascript”가 Array 나 Object 메소드 구현보다 더 고유 한 것처럼. 헤이즈 …

단 하나의 진실의 근원을 갖는 것이 좋을 것입니다. 다른 말을 들었더라도 내 사랑하는 바닐라 신은 없습니다. 죄송 해요. 실제로 유일하게 가정하는 것은 모든 주요 브라우저에서 우수한 성능을 목표로 Javascript 코드를 작성하고 있으며 모두 동일한 구현을 가지고 있다는 것을 알고 있습니다. 부드럽게 대처하는 것은 나쁜 일입니다. 그러나 그것은 당신이 좋아하든 아니든 전제입니다.

어쩌면 트위터 성능이 필요한 대규모 프로젝트를 진행하고 있기 때문에 지금 당 초당 목록에서 850,000 (밑줄)과 2,500,000 (lodash) 반복 의 차이를 실제로 볼 수 있습니다!

나는 한 사람이 아닙니다. 나는 성능 문제를 해결 해야하는 프로젝트를 수행했지만 결코 밑줄이나 Lo-Dash로 해결되거나 발생하지 않았습니다. 그리고 구현과 성능의 실제 차이점 (현재 C ++과 이야기하고 있음)을 반복하지 않으면 반복 가능 (객체 또는 배열, 희소 여부)에 대한 루프를 말할 수 있습니다. 이미 평가 된 벤치 마크 플랫폼의 결과에 근거한 주장 .

Rhino는 단 하나의 업데이트만으로도 단일 “중세 루프 방법이 더 우수하고 영원하며 성능이 우수하지 않다”는 사제가 모든 사실이 FF의 갑작스런 배열 방법은 자신이 생각한 것보다 훨씬 빠릅니다. 런타임 환경을 속여서 런타임 환경을 속일 수는 없습니다! 홍보 할 때 생각하십시오 …

다용도 벨트

다음에

따라서 관련성을 유지하려면 :

  • 네이티브 ish를 희생하지 않고 편리하다면 Underscore를 사용하십시오.
  • 확장 기능 카탈로그 (딥 카피 등)가 편리하고 즉각적인 성능이 절실히 필요하고 네이티브 API가 나 오자마자 대안을 결정하지 않아도되는 경우 Lo-Dash를 사용하십시오. 의견이있는 해결 방법. 곧 일어날 것입니다. 기간.
  • 세 번째 해결책조차 있습니다. DIY! 환경을 알고 있어야합니다. 불일치에 대해 알아야합니다. ( John-David 와 Jeremy 의) 코드를 읽으십시오 . 일관성 / 호환성 계층이 실제로 필요한 이유를 설명 할 수없고이를 사용하지 말고 워크 플로를 향상 시키거나 앱의 성능을 향상 시키십시오. 완벽하게 작성할 수있는 간단한 폴리 필로 요구 사항이 충족 될 가능성이 큽니다. 두 라이브러리 모두 약간의 설탕이 들어간 바닐라입니다. 그들은 둘 다 누가 가장 달콤한 파이를 제공하는지 싸우고 있습니다. 그러나 결국 두 가지 모두 물로만 요리한다고 믿습니다. 바닐라 신이 없어서 바닐라 교황도 없어요?

귀하의 요구에 가장 적합한 방법을 선택하십시오. 평소와 같이. 나는 의견이 많은 런타임 치트에 대한 실제 구현에 대한 대체를 언제든지 선호하지만 요즘에는 맛의 문제 인 것 같습니다. http://developer.mozilla.com 및 http://caniuse.com 과 같은 양질의 리소스를 사용 하면 괜찮을 것입니다.

답변

나는 여기에 언급 된 대부분의 것에 동의하지만 단지 underscore.js에 찬성하는 주장을 지적하고 싶습니다 : 라이브러리의 크기.

특히 모바일 장치에서 주로 사용하려는 앱이나 웹 사이트를 개발하는 경우 결과 번들의 크기와 부팅 또는 다운로드 시간에 미치는 영향이 중요한 역할을 할 수 있습니다.

비교를 위해,이 크기는 이온 서브를 실행 한 후 소스 맵 탐색기에서 발견 된 크기입니다.

lodash: 523kB
underscore.js: 51.6kb

2020 년 2 월 수정 :

BundlePhobia 를 사용 하여 Lo-Dash 및 Underscore 의 현재 크기를 확인할 수 있습니다.

답변

그것이 OP가 무엇인지 확실하지는 않지만 밑줄에서 lodash로 마이그레이션 할 때 명심 해야하는 문제 목록을 검색했기 때문에이 질문에 맞서게되었습니다.

누군가가 그러한 차이점의 전체 목록이있는 기사를 게시 한 경우 정말 감사하겠습니다. 어려운 방법으로 배운 것들, 즉 프로덕션에서 코드가 폭발하게 된 것들로 시작하겠습니다.

  • _.flatten밑줄은 기본적으로 깊고 두 번째 인수로 true를 전달하여 얕게 만듭니다. lodash에서는 기본적으로 얕고 두 번째 인수로 true를 전달하면 깊어집니다! 🙂
  • _.last밑줄은 원하는 요소 수를 나타내는 두 번째 인수를 허용합니다. 에서 lodash이러한 옵션이 없습니다. 당신은 이것을 모방 할 수 있습니다.slice
  • _.first (같은 문제)
  • _.template밑줄에서 여러 가지 방법으로 사용할 수 있습니다. 그중 하나는 템플릿 문자열과 데이터를 제공하고 HTML돌아 오는 것입니다 (또는 적어도 얼마 전에 작동했던 방식입니다). 에서 lodash당신이 그런 다음 데이터를 공급해야하는 함수를받을 수 있습니다.
  • _(something).map(foo)밑줄로 작동하지만 lodash에서는로 다시 작성해야했습니다 _.map(something,foo). 아마도 그것은 단지 문제 TypeScript였습니다.