Consider moving to use Lodash rather than Underscore about mingo HOT 13 CLOSED

@kofrasa
I forgot to mention, some other reasons in favor of Lodash:

1. Extensive community participation and inclusion (thanks to @jdalton for showing everyone how to do OSS leadership)
2. Rigorous testing.
3. Leading Performance in most head-to-head comparisons. (emphasis on the common uses)
4. Typically ZERO outstanding bugs.
5. Also, a very short average delay until bugs are resolved.
6. A vastly larger user base, Lodash flew past underscore in monthly downloads about a year or 2 ago.

https://npmcompare.com/compare/lazy.js,lodash,ramda,underscore

from mingo.

@justsml

I think you provide good arguments for lodash however, I am not convinced they justify making a dependency change given a few practical reasons unrelated to the library itself.

1. underscore was chosen for quick prototyping and not meant to be a permanent dependency. My goal is to make this a zero-dependency library before v1.0.0. The most frequently used _ functions are trivial to implement, and others can be optimised to meet the needs of this project even better. See function usage stats below.
2. The dependency has not been a major issue and changing it directly impacts all other users relying on underscore even though this request is being voted for by a few AFAIK.
3. Subject to point (1), it is better to resume work on removing the dependency completely rather than replacing it with another.

I think part of the motivation for this was mistakenly assuming that switching to lodash would have resolved the bug in issue#25. I do appreciate the contribution and encourage participation but I believe the reasons I provide give some more context as to why the alternative is preferable.

I would like to know your thoughts before we proceed from here.

Function usage stats from underscore library:

     24 each
     15 keys
     15 contains
     12 isEmpty
     10 extend
      7 find
      6 map
      6 has
      5 intersection
      3 uniq
      3 reduce
      2 difference
      1 without
      1 union
      1 sortBy
      1 some
      1 result
      1 rest
      1 pick
      1 omit
      1 min
      1 max
      1 isEqual
      1 flatten
      1 first
      1 filter
      1 every
      1 defaults

from mingo.

I just built such a contraption @jdalton (thanks for chiming in, you always seem to hear lodash being uttered anywhere in the universe... It's like your bat signal; have you ever called lodash your utility belt?)

... ok ok, i know i @ mentioned you

Thanks for the explanation @kofrasa ... I'll PR my webpack/babel script.
Then do another PR removing the core of the obviated methods (like you mention each, keys, etc.)

from mingo.

^^^ I'm working under the assumption that the remaining lodash dependency size will be smaller than the bundle output by including underscore.

And for existing users, the nice feature here is the bundle internalizes the dependencies in a closure.
So it only increases supported environments/sites.
This also makes the bundle more immune to library version differences out in the wild.

from mingo.

@zackehh my PR #27 is almost passing...

Can you take a look and see if you can help me get the last few tests to pass?

from mingo.

@justsml I can only assume that Lodash is doing some rebinding under the hood for some reason, it all looks ok to me - the issue must be with that _.filter call

from mingo.

So close...

@zackehh Down to 1 failing test... 😿

https://travis-ci.org/kofrasa/mingo/builds/159784057#L255

Something in the aggregate for $max... or thereabouts.

from mingo.

It passes!!!

✅ 👍

from mingo.

I think I responded to this partly in the previous issue: issue#25

I do not see the benefit to using lodash over underscore.

What is the justification for this?

from mingo.

Hi @kofrasa - sorry, i just realized we skipped the foreplay.
The main reasons I use Lodash is it's larger (& superior) API, Functional Programming support and multiple ways of doing composition (compose, flow, flowRight, et. al.).

Additionally, Lodash has a better modular design (in it's internal shared dependancies) which leads to smaller bundle size.

Leading to my next point, I've been writing a webpack script to create a stand-alone browser bundle.

Aside from it being easier to implement in an existing site, the total download size will be reduced and the overall JS code paths will be optimized with dead path pruning.

Underscore just is not designed to take advantage of all this to the same degree.

Full disclosure: I worked with @jdalton on DataView/ArrayBuffer support in lodash.

Some research from @alekseykulikov - https://gist.github.com/alekseykulikov/5f4a6ca69e7b4ebed726

from mingo.

FWIW with Lodash you can use babel-plugin-lodash and lodash-webpack-plugin to bundle in just the methods you need without having to re-implement and maintain their equivs or require a separate dep.

from mingo.

Resolving in view of latest development.

from mingo.

@kofrasa
It looks like you just reimplemented a ton of methods 😿
Even shimming is better done with something like es-shims.

from mingo.