6 ms·

Am I the only one who feels that it's not a terrible thing to use Lodash? It's relatively small gzipped (4kb for core build), a single interface for a developer

by nemild 7y ago

Am I the only one who feels that it's not a terrible thing to use Lodash? It's relatively small gzipped (4kb for core build), a single interface for a developer to learn, and means you don't have to think as much about the target browser. Sure it adds a dependency, but an incremental dependency isn't often an issue. The .chunk is a good example (a 7 line function in native vs a 1 line function in Lodash). I imagine some native functions are faster, but often it doesn't matter. I say this only partially jokingly: maybe there should be a "You don't need javascript," and we should go back to assembly.

dubcanada 7y ago
The rest it's 7 line versus 1 line is lodash uses itself. A lot of these functions could be rewritten if other functions where there. I do think it's silly to include 100 functions and use 2. But if we could properly tree shake lodash there should be no problem in using lodash, you would end up around the same as if you did it natively.
- larc 7y ago
  You can add individual lodash functions to your project. That's what we do to keep our Lambda's a little more lightweight. https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
- nemild 7y ago
  But don't we all use a small fraction of library/package and language functionality. - In C's stdio, I've used a fraction of calls - In Ruby/Rails + gems, I use a fraction of calls - In Node/Express, I use a fraction of calls - In frontend javascript, I use a fraction of the native calls In frontend dev, I get that this means forcing users to download a library, but for many use cases 4 kb gzipped isn't a big deal (esp if CDNs are involved). I think it'd be interesting to poll developers on what part of Lodash/Underscore causes them concern: 1. The extra download time/bandwidth 2. The extra costs of packaging (failed builds, extra packaging process) 3. The speed of computation (assuming that some native functions are faster) 4. The concern that libraries should only be used when they are highly utilized (e.g., at least 20% of a library's code should be used before it is appropriate to include it)
  - Izkata 7y ago
    > In frontend dev, I get that this means forcing users to download a library, but for many use cases 4 kb gzipped isn't a big deal (esp if CDNs are involved). How about 0kb? Whatever happened to shared-resource URLs, where there was a good chance the library was already cached?
    - zdragnar 7y ago
      Your breaks or has minimal functionality if the CDN is down. Your site loads slowly if the CDN is under load Your users are now leaked to the CDN (privacy issue) Of course, if the resource is cached, it's less of an issue, but it's still an issue. If you don't care about those things, go ahead.
dokka 7y ago
I agree, also. The code in lodash is arguably better than mine, and they are more experienced than I.
- agumonkey 7y ago
  and surely extremely battle tested

by nemild 7y ago

dubcanada 7y ago

The rest it's 7 line versus 1 line is lodash uses itself. A lot of these functions could be rewritten if other functions where there. I do think it's silly to include 100 functions and use 2. But if we could properly tree shake lodash there should be no problem in using lodash, you would end up around the same as if you did it natively.

larc 7y ago
You can add individual lodash functions to your project. That's what we do to keep our Lambda's a little more lightweight. https://www.npmjs.com/search?q=keywords:lodash-modularized https://www.npmjs.com/search?q=keywords:lodash-modularized
nemild 7y ago
But don't we all use a small fraction of library/package and language functionality. - In C's stdio, I've used a fraction of calls - In Ruby/Rails + gems, I use a fraction of calls - In Node/Express, I use a fraction of calls - In frontend javascript, I use a fraction of the native calls In frontend dev, I get that this means forcing users to download a library, but for many use cases 4 kb gzipped isn't a big deal (esp if CDNs are involved). I think it'd be interesting to poll developers on what part of Lodash/Underscore causes them concern: 1. The extra download time/bandwidth 2. The extra costs of packaging (failed builds, extra packaging process) 3. The speed of computation (assuming that some native functions are faster) 4. The concern that libraries should only be used when they are highly utilized (e.g., at least 20% of a library's code should be used before it is appropriate to include it)
- Izkata 7y ago
  > In frontend dev, I get that this means forcing users to download a library, but for many use cases 4 kb gzipped isn't a big deal (esp if CDNs are involved). How about 0kb? Whatever happened to shared-resource URLs, where there was a good chance the library was already cached?
  - zdragnar 7y ago
    Your breaks or has minimal functionality if the CDN is down. Your site loads slowly if the CDN is under load Your users are now leaked to the CDN (privacy issue) Of course, if the resource is cached, it's less of an issue, but it's still an issue. If you don't care about those things, go ahead.

dokka 7y ago

I agree, also. The code in lodash is arguably better than mine, and they are more experienced than I.

agumonkey 7y ago
and surely extremely battle tested