Sự khác nhau giữa lodash và gạch dưới [đóng]

Tại sao ai đó thích thư viện tiện ích lodash.js hoặc underscore.js hơn thư viện khác?

Lodash dường như là một sự thay thế thả xuống cho gạch dưới, cái sau đã tồn tại lâu hơn.

Tôi nghĩ cả hai đều tuyệt vời, nhưng tôi không biết đủ về cách họ làm việc để tạo ra một so sánh có giáo dục, và tôi muốn biết thêm về sự khác biệt.

Tôi đã tạo Lo-Dash để cung cấp hỗ trợ lặp lại môi trường chéo nhất quán hơn cho các mảng, chuỗi, đối tượng và argumentsđối tượng ¹ . Nó đã trở thành một siêu ký tự của Underscore, cung cấp hành vi API phù hợp hơn, nhiều tính năng hơn (như hỗ trợ AMD, nhân bản sâu và hợp nhất sâu), kiểm tra tài liệu và đơn vị kỹ lưỡng hơn (các thử nghiệm chạy trong Node, Ringo, Rhino, Narwhal, PhantomJS và trình duyệt), hiệu suất tổng thể tốt hơn và tối ưu hóa cho các mảng / lặp đối tượng lớn và linh hoạt hơn với các bản dựng tùy chỉnh và các tiện ích tiền biên dịch mẫu.

Vì Lo-Dash được cập nhật thường xuyên hơn Underscore, nên một bản lodash underscoredựng được cung cấp để đảm bảo khả năng tương thích với phiên bản ổn định mới nhất của Underscore.

Tại một thời điểm, tôi thậm chí còn được cấp quyền truy cập vào Underscore, một phần vì Lo-Dash chịu trách nhiệm đưa ra hơn 30 vấn đề; sửa lỗi hạ cánh, các tính năng mới và tăng hoàn hảo trong Underscore v1.4.x +.

Ngoài ra, có ít nhất 3 mẫu nồi hơi xương sống bao gồm Lo-Dash theo mặc định và Lo-Dash hiện được đề cập trong tài liệu chính thức của Backbone .

Kiểm tra bài đăng của Kit Cambridge, nói "Xin chào" với Lo-Dash , để biết thêm chi tiết về sự khác biệt giữa Lo-Dash và Underscore.

Chú thích:

1. Underscore có sự hỗ trợ không nhất quán cho mảng, chuỗi, đối tượng và argumentsđối tượng. Trong các trình duyệt mới hơn, các phương thức Underscore bỏ qua các lỗ hổng trong mảng , các phương thức "Đối tượng" lặp lại argumentscác đối tượng, các chuỗi được coi là giống như mảng và các phương thức lặp lại chính xác các hàm (bỏ qua thuộc tính "nguyên mẫu" của chúng) và các đối tượng (lặp lại các thuộc tính bị bóng như "toString" và "valueOf"), trong khi trong các trình duyệt cũ hơn thì không. Ngoài ra, các phương thức gạch dưới như _.clonebảo toàn các lỗ trong mảng, trong khi các phương pháp khác _.flattenthì không.

Lo-Dash được lấy cảm hứng từ gạch dưới, nhưng ngày nay là giải pháp ưu việt. Bạn có thể tạo các bản dựng tùy chỉnh của mình , có hiệu suất cao hơn , hỗ trợ AMD và có các tính năng bổ sung tuyệt vời . Kiểm tra điểm chuẩn Lo-Dash vs Underscore này trên jsperf và .. bài đăng tuyệt vời này về lo-dash :

Một trong những tính năng hữu ích nhất khi bạn làm việc với các bộ sưu tập, là cú pháp tốc ký:

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

(lấy từ tài liệu lodash )

Nếu giống như tôi, bạn đang mong đợi một danh sách các khác biệt về cách sử dụng giữa gạch dưới và lodash, thì có một hướng dẫn để chuyển từ gạch dưới sang lodash .

Đây là trạng thái hiện tại của nó cho hậu thế:

• Gạch dưới _.anylà Lodash_.some
• Gạch dưới _.alllà Lodash_.every
• Gạch dưới _.composelà Lodash_.flowRight
• Gạch dưới _.containslà Lodash_.includes
• Gạch dưới _.eachkhông cho phép thoát bằng cách quay lạifalse
• Gạch dưới _.findWherelà Lodash_.find
• Underscore _.flattenlà sâu theo mặc định trong khi Lodash nông
• Underscore _.groupByhỗ trợ một iteratee được truyền các tham số (value, index, originalArray), trong khi ở Lodash, iteratee _.groupBychỉ được truyền một tham số duy nhất : (value).
• Gạch dưới _.indexOfvới tham số thứ 3 undefinedlà Lodash_.indexOf
• Gạch dưới _.indexOfvới tham số thứ 3 truelà Lodash_.sortedIndexOf
• Gạch dưới _.indexBylà Lodash_.keyBy
• Gạch dưới _.invokelà Lodash_.invokeMap
• Gạch dưới _.mapObjectlà Lodash_.mapValues
• Underscore _.maxkết hợp Lodash _.max&_.maxBy
• Underscore _.minkết hợp Lodash _.min&_.minBy
• Underscore _.samplekết hợp Lodash _.sample&_.sampleSize
• Underscore _.objectkết hợp Lodash _.fromPairsvà_.zipObject
• Gạch dưới _.omitbởi một vị ngữ là Lodash_.omitBy
• Gạch dưới _.pairslà Lodash_.toPairs
• Gạch dưới _.pickbởi một vị ngữ là Lodash_.pickBy
• Gạch dưới _.plucklà Lodash_.map
• Underscore _.sortedIndexkết hợp Lodash _.sortedIndex&_.sortedIndexOf
• Gạch dưới _.uniqbởi một iterateelà Lodash_.uniqBy
• Gạch dưới _.wherelà Lodash_.filter
• Underscore _.isFinitekhông phù hợp với Number.isFinite
  (ví dụ _.isFinite('1')trả về truetrong Underscore nhưng falsetrong Lodash)
• Tốc _.matcheský gạch dưới không hỗ trợ so sánh sâu
  (ví dụ _.filter(objects, { 'a': { 'b': 'c' } }))
• Gạch dưới ≥ 1.7 & _.templateCú pháp tạm dừng là
  _.template(string, option)(data)
• Bộ _.memoizeđệm tạm thời Mapgiống như đồ vật
• Lodash không hỗ trợ một contextđối số cho nhiều phương pháp có lợi cho_.bind
• Lodash hỗ trợ chuỗi ngầm , chuỗi lười biếng và hợp nhất phím tắt
• Lodash chia nó quá tải _.head, _.last, _.rest, & _.initialra vào
  _.take, _.takeRight, _.drop, & _.dropRight
  (nghĩa là _.head(array, 2)trong dấu gạch dưới là _.take(array, 2)trong Lodash)

Ngoài câu trả lời của John, và đọc lên lodash (mà tôi đã coi là "tôi cũng vậy", và xem các bài kiểm tra hiệu suất, đọc mã nguồn và bài đăng trên blog , một vài điểm tạo ra lodash vượt trội hơn nhiều so với gạch dưới là:

1. Đó không phải là về tốc độ, mà là về sự nhất quán của tốc độ (?)

   Nếu bạn nhìn vào mã nguồn của gạch dưới, bạn sẽ thấy trong một vài dòng đầu tiên gạch dưới trở lại các triển khai gốc của nhiều hàm. Mặc dù trong một thế giới lý tưởng, đây sẽ là một cách tiếp cận tốt hơn, nếu bạn nhìn vào một số liên kết hoàn hảo được đưa ra trong các slide này , không khó để đưa ra kết luận rằng chất lượng của những 'triển khai bản địa' đó thay đổi rất nhiều trình duyệt- trình duyệt. Firefox rất nhanh trong một số chức năng và trong một số Chrome chiếm ưu thế. (Tôi tưởng tượng sẽ có một số kịch bản mà IE cũng sẽ thống trị). Tôi tin rằng tốt hơn là thích một mã có hiệu suất phù hợp hơn trên các trình duyệt.

   Đừng đọc bài đăng trên blog sớm hơn và thay vì tin vào điều đó, hãy tự đánh giá bản thân bằng cách chạy các điểm chuẩn . Tôi choáng váng ngay bây giờ, khi thấy một lodash hoạt động nhanh hơn 100-150% so với gạch dưới trong các chức năng nguyên gốc , đơn giản như trong Chrome!Array.every

2. Các tính năng bổ sung trong lodash cũng khá hữu ích.

3. Đối với nhận xét được đánh giá cao của Xananax cho thấy đóng góp cho mã gạch dưới: Luôn luôn tốt hơn để cạnh tranh TỐT , không chỉ giúp cải tiến mà còn giúp bạn giữ cho mình (hoặc thư viện của bạn) ở trạng thái tốt.

Dưới đây là danh sách các điểm khác biệt giữa lodash và bản gạch dưới của nó là sự thay thế thả xuống cho các dự án gạch dưới của bạn.

Đây là năm 2014 và một vài năm quá muộn. Tôi vẫn nghĩ rằng quan điểm của tôi là:

IMHO cuộc thảo luận này đã bị thổi ra khỏi tỷ lệ khá nhiều. Trích dẫn bài viết trên blog nói trên :

Hầu hết các thư viện tiện ích JavaScript, chẳng hạn như Underscore, Valentine và wu, đều dựa vào cách tiếp cận kép đầu tiên của bản địa. Cách tiếp cận này thích các triển khai gốc hơn, chỉ quay lại JavaScript vanilla nếu không hỗ trợ tương đương gốc. Nhưng jsPerf đã tiết lộ một xu hướng thú vị: cách hiệu quả nhất để lặp lại một bộ sưu tập giống như mảng hoặc là tránh hoàn toàn các triển khai gốc, thay vào đó chọn các vòng lặp đơn giản.

Như thể "các vòng lặp đơn giản" và "vanilla Javascript" có nguồn gốc hơn các triển khai phương thức Array hoặc Object. Trời ...

Chắc chắn sẽ rất tốt nếu có một nguồn sự thật, nhưng không có. Ngay cả khi bạn được nói khác đi, không có Thần Vanilla, em yêu. Tôi xin lỗi. Giả định duy nhất thực sự đúng là tất cả chúng ta đều đang viết mã Javascript nhằm mục đích hoạt động tốt trong tất cả các trình duyệt chính, biết rằng tất cả chúng đều có các triển khai khác nhau của cùng một thứ. Đó là một con chó cái để đối phó với, để nói một cách nhẹ nhàng. Nhưng đó là tiền đề, dù bạn có thích hay không.

Có thể bạn đang làm việc trên các dự án quy mô lớn cần hiệu suất twitter để bạn thực sự thấy sự khác biệt giữa 850.000 (gạch dưới) so với 2.500.000 (lặp lại) trong một danh sách mỗi giây ngay bây giờ!

Tôi cho một người không. Ý tôi là, tôi đã làm việc với các dự án mà tôi phải giải quyết các vấn đề về hiệu suất, nhưng chúng không bao giờ được giải quyết hoặc gây ra bởi cả Underscore và Lo-Dash. Và trừ khi tôi nắm được sự khác biệt thực sự trong triển khai và hiệu suất (chúng ta đang nói về C ++ ngay bây giờ), hãy nói một vòng lặp trên một vòng lặp (đối tượng hoặc mảng, thưa thớt hay không!), Tôi không bị làm phiền với bất kỳ khiếu nại dựa trên kết quả của một nền tảng chuẩn đã được quan tâm .

Rhino chỉ cần một bản cập nhật duy nhất cho phép Rhino thiết lập các triển khai phương thức Array của mình theo cách mà không một phương thức "vòng lặp thời trung cổ nào hoạt động tốt hơn và mãi mãi" và linh mục có thể tranh luận theo cách của mình xung quanh sự thật đơn giản rằng tất cả một phương thức mảng đột ngột trong FF nhanh hơn nhiều so với phương pháp cân não của anh ấy / cô ấy. Man, bạn không thể lừa dối môi trường thời gian chạy của bạn bằng cách gian lận môi trường thời gian chạy của bạn! Hãy nghĩ về điều đó khi quảng bá ...

vành đai tiện ích của bạn

... lần tới.

Vì vậy, để giữ cho nó có liên quan:

• Sử dụng Underscore nếu bạn thuận tiện mà không phải hy sinh bản địa.
• Sử dụng Lo-Dash nếu bạn thấy thuận tiện và thích danh mục tính năng mở rộng của nó (bản sao sâu, v.v.) và nếu bạn đang rất cần hiệu suất tức thì và quan trọng nhất là đừng bận tâm đến việc thay thế ngay khi API gốc workauround ý kiến. Điều đó sẽ xảy ra sớm. Giai đoạn = Stage.
• Thậm chí còn có một giải pháp thứ ba. Tự làm! Biết môi trường của bạn. Biết về sự không nhất quán. Đọc mã của họ ( John-David và Jeremy ). Không sử dụng cái này hoặc cái kia mà không thể giải thích tại sao một lớp nhất quán / tương thích là thực sự cần thiết và tăng cường quy trình làm việc của bạn hoặc cải thiện hiệu suất của ứng dụng của bạn. Rất có khả năng các yêu cầu của bạn được thỏa mãn với một polyfill đơn giản mà bạn hoàn toàn có thể tự viết. Cả hai thư viện chỉ là vani đơn giản với một chút đường. Cả hai chỉ chiến đấu vì những người phục vụ những chiếc bánh ngọt ngào nhất . Nhưng tin tôi đi, cuối cùng cả hai chỉ nấu với nước. Không có Thần Vanilla nên không thể không có giáo hoàng Vanilla, phải không?

Chọn bất cứ cách tiếp cận nào phù hợp với nhu cầu của bạn nhất. Như thường lệ. Tôi thích dự phòng cho việc triển khai thực tế hơn gian lận thời gian chạy có ý kiến ​​bất cứ lúc nào nhưng ngay cả điều đó dường như là một vấn đề của hương vị ngày nay. Bám sát các tài nguyên chất lượng như http://developer.mozilla.com và http://caniuse.com và bạn sẽ ổn thôi.

Tôi đồng ý với hầu hết những điều được nói ở đây nhưng tôi chỉ muốn chỉ ra một đối số có lợi cho underscore.js: kích thước của thư viện.

Đặc biệt trong trường hợp bạn đang phát triển một ứng dụng hoặc trang web có ý định sử dụng chủ yếu trên thiết bị di động, kích thước của gói kết quả và ảnh hưởng đến thời gian khởi động hoặc tải xuống có thể có một vai trò quan trọng.

Để so sánh, các kích thước này là những kích thước tôi nhận thấy với trình thám hiểm nguồn-map sau khi chạy phục vụ ion:

lodash: 523kB
underscore.js: 51.6kb

chỉnh sửa tháng 2 năm 2020 :

người ta có thể sử dụng BundlePhobia để kiểm tra kích thước hiện tại của Lo-Dash và Underscore

Không chắc đó có phải ý của OP không, nhưng tôi đã gặp phải câu hỏi này bởi vì tôi đang tìm kiếm một danh sách các vấn đề tôi phải ghi nhớ khi chuyển từ gạch dưới sang lodash.

Tôi thực sự sẽ đánh giá cao nếu ai đó đăng một bài viết với một danh sách đầy đủ về sự khác biệt như vậy. Hãy để tôi bắt đầu với những điều tôi đã học được một cách khó khăn (đó là, những điều làm cho mã của tôi bùng nổ khi sản xuất: /):

• _.flattentrong gạch dưới là sâu theo mặc định và bạn phải truyền đúng như đối số thứ hai để làm cho nó nông. Trong lodash, nó mặc định là nông và truyền đúng như đối số thứ hai sẽ làm cho nó sâu sắc! :)
• _.lasttrong gạch dưới chấp nhận một đối số thứ hai cho biết bạn muốn bao nhiêu phần tử. Tronglodash đó không có lựa chọn như vậy. Bạn có thể mô phỏng điều này với.slice
• _.first (cùng một vấn đề)
• _.templatetrong gạch dưới có thể được sử dụng theo nhiều cách, một trong số đó là cung cấp chuỗi mẫu và dữ liệu và lấy HTMLlại (hoặc ít nhất đó là cách nó hoạt động cách đây một thời gian). Tronglodash bạn nhận được một chức năng mà sau đó bạn sẽ cung cấp dữ liệu.
• _(something).map(foo)hoạt động trong gạch dưới, nhưng trong lodash tôi đã phải viết lại nó _.map(something,foo). Có lẽ đó chỉ là một sự TypeScriptban hành

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

Bài viết mới nhất so sánh hai của Ben McCormick:

1. API của Lo-Dash là một siêu nhóm của Underscore.

2. Dưới mui xe [Lo-Dash] đã được viết lại hoàn toàn.

3. Lo-Dash chắc chắn không chậm hơn Underscore.

4. Lo-Dash đã thêm gì?

   • Cải tiến khả năng sử dụng
   • Chức năng bổ sung
   • Hiệu suất đạt được
   • Cú pháp tốc ký cho chuỗi
   • Bản dựng tùy chỉnh để chỉ sử dụng những gì bạn cần
   • Phiên bản ngữ nghĩa và bảo hiểm mã 100%

Tôi chỉ tìm thấy một sự khác biệt cuối cùng là quan trọng đối với tôi. Các phiên bản không tương thích với gạch của lodash của _.extend()không không sao chép trên các thuộc tính hoặc phương thức được xác định ở cấp độ lớp.

Tôi đã tạo một thử nghiệm Jasmine trong CoffeeScript để chứng minh điều này:

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

May mắn thay, lodash.underscore.jsduy trì hành vi sao chép mọi thứ của Underscore, mà đối với tình huống của tôi là hành vi mong muốn.

lodash có _.mapValues()cái giống hệt với underescore _.mapObject().

Đối với hầu hết các phần gạch dưới là tập con của lodash. Đôi khi, giống như hiện tại gạch dưới sẽ có các chức năng nhỏ thú vị mà lodash không có như mapObject. Điều này giúp tôi tiết kiệm rất nhiều thời gian trong việc phát triển dự án của tôi.

Chúng khá giống nhau, với Lodash đang tiếp quản ...

Cả hai đều là một thư viện tiện ích bao gồm thế giới tiện ích trong JavaScript ...

Có vẻ như Lodash đang được cập nhật thường xuyên hơn bây giờ, vì vậy được sử dụng nhiều hơn trong các dự án mới nhất ...

Ngoài ra, Lodash dường như nhẹ hơn bởi một vài KB ...

Cả hai đều có một api và doc tốt, nhưng tôi nghĩ rằng Lodash one tốt hơn ...

Dưới đây là ảnh chụp màn hình cho mỗi tài liệu để nhận giá trị đầu tiên của một mảng ...

gạch dưới:

nhà nghỉ:

Vì mọi thứ có thể được cập nhật theo thời gian, chỉ cần kiểm tra trang web của họ ...

nhà nghỉ

gạch dưới