Hacker News Reader

Comment by xiaoma | Hacker News Reader

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.

View on HN

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.

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!

'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.

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.

Core build (~4 kB gzipped)

Full build (~22 kB gzipped)

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.

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