Hacker News Reader

Comment by have_faith | Hacker News Reader

Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.

View on HN

Lodash has published packages with their individual functions, so you can strip down to what you need (and put together your own build if you so desire). For example:

https://www.npmjs.com/package/lodash.throttle

https://www.npmjs.com/package/lodash.debounce

Alternatively, if you use a modern web bundling system (like Webpack, for all its warts), you can just import the function directly

    import merge from `lodash/merge`
    merge(options, overrides)

There's also the ES6 build which you can use better with a bundling system that supports tree shaking.

Throttle and debounce are top of my list as well

Might be a good idea to use a polyfill (like core-js) to ensure the api exists. On modern browsers it would just use the native impl.

Not much to gain though. Just importing lodash works fine.

core-js is the truck factor single point of failure of modern JS development.

There's not many good alternative (there's a lot of alternative, but none that are as comprehensive), essentially has ONE person really working on it (and threatening to stop imminently), and the code is unreadable, so hopping into it once said maintainer goes poof will be tricky.

We still depend on it (no great alternative), but it's a ticking time bomb IMO.

You should check out

https://github.com/lodash/babel-plugin-lodash

https://github.com/lodash/lodash-webpack-plugin

If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.

Didn't someone do a study and found that cache hit rates for CDNs were in the 10-20% range?

You might be better off bundling lodash and tree shaking everything you don't actually use away.

And it will also lead to the site not working out-of-the-box for privacy-conscious people like me who block third-party JS by default.

'third party JS' is really a synonym for 'third party hosted JS' and they're not a very exact match. You might block mixpanel but I can make my own analytics.

Well you can avoid that with an inline script that checks for it and includes it from a local path if it fails.

But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...)

> But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...)

I have a friend who has done, in production, exactly what your subconscious is afraid of. I should get him to do a write up sometime: it's both amazing and horrifying at the same time...

I'd actually love to see that!

I've thought about it a bit before, and always ignored it because there'd be no real benefit.

But i could see writing a crazy webpack config that breaks out all my lodash functions into their own bundle, then tries to add a script tag to the CDN version, doing some quick processing to determine if it's in the cache, and if it's not falling back to including my own custom-built script tag (and canceling the request to the CDN version).

I'm sure it wouldn't provide any benefit to anyone, but it would be a fun code-golf exercise!

If he is building his code then he is probably bundling and minifying his entire client source together and being selective just keeps the build code smaller. Having one request for all of the client is more preferable to some. Anyways, I'm just saying I don't think he is just building a minified fork of lodash.

I shouldn't have said fork since it is just building but oh well.

> If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.

Only if each site is using the exact same version of Lodash which is unlikely. Lodash is tiny anyways.

Actually, a full version of loadash is not insignificant.

You might dig

https://github.com/lodash/lodash-webpack-plugin

We do plenty fine with just `import get from 'lodash/get', however we're fairly eager to upgrade to webpack to to take advantage of it's tree-shaking capabilities.

Webpack 2 or Rollup don't tree-shake Lodash well.

You'll need something like https://github.com/lodash/babel-plugin-lodash.

Compared to what? I meant in the sense that the full gzipped version wouldn't even be as big as a single small image on a website.

Core build (~4 kB gzipped)

Full build (~22 kB gzipped)

If you only need a couple of functions though, and makes your JS bundle just a few bytes bigger, getting the whole thing from the CDN is kind of silly.

Especially for those with empty cache (need to make 1 extra DNS request, download 1 extra file, which is mostly unneeded, etc).

Reply on news.ycombinator.com