3 ms·

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

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.

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.