Hacker News Reader

Comment by nemild | Hacker News Reader

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.

View on HN

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

and surely extremely battle tested

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.

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

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)

> 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?

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.

Reply on news.ycombinator.com