4 ms·
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.
by xiaoma 10y ago
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.
- Klathmon 10y agoDidn'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.
- majewsky 10y agoAnd 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.
- Klathmon 10y agoWell 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...)
- girvo 10y ago> 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...
- Klathmon 10y agoI'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!
- nailer 10y ago'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.
- busheezy 10y agoIf 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.
- busheezy 10y agoI shouldn't have said fork since it is just building but oh well.
- kolme 10y agoIf 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).
- seanwilson 10y ago> 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.
- madeofpalk 10y agoActually, a full version of loadash is not insignificant.
- jdd 10y agoYou might dig https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin
- madeofpalk 10y agoWe 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.
- jdd 10y agoWebpack 2 or Rollup don't tree-shake Lodash well. You'll need something like https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/babel-plugin-lodash.
- joshstrange 10y agoCore build (~4 kB gzipped) Full build (~22 kB gzipped)
- seanwilson 10y agoCompared 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.