4 ms·

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

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.

test1235 10y ago
Throttle and debounce are top of my list as well
eknkc 10y ago
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.
- shados 10y ago
  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.
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 ago
  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.
  - majewsky 10y ago
    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.
    - Klathmon 10y ago
      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...)
      - 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 ago
        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!
    - 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 ago
  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.
  - busheezy 10y ago
    I shouldn't have said fork since it is just building but oh well.
- kolme 10y ago
  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).
- 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 ago
    Actually, a full version of loadash is not insignificant.
    - jdd 10y ago
      You might dig https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin
      - madeofpalk 10y ago
        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.
        jdd 10y ago
        Webpack 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 ago
      Core build (~4 kB gzipped) Full build (~22 kB gzipped)
    - seanwilson 10y ago
      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.
ascagnel_ 10y ago
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.throttle https://www.npmjs.com/package/lodash.debounce https://www.npmjs.com/package/lodash.debounce
- madeofpalk 10y ago
  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.
jdd 10y ago
You should check out https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin

test1235 10y ago

Throttle and debounce are top of my list as well

eknkc 10y ago

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.

shados 10y ago
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.

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 ago
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.
- majewsky 10y ago
  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.
  - Klathmon 10y ago
    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...)
    - 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 ago
        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!
  - 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 ago
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.
- busheezy 10y ago
  I shouldn't have said fork since it is just building but oh well.
kolme 10y ago
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).
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 ago
  Actually, a full version of loadash is not insignificant.
  - jdd 10y ago
    You might dig https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin
    - madeofpalk 10y ago
      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.
      - jdd 10y ago
        Webpack 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 ago
    Core build (~4 kB gzipped) Full build (~22 kB gzipped)
  - seanwilson 10y ago
    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.

ascagnel_ 10y ago

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.throttle https://www.npmjs.com/package/lodash.debounce https://www.npmjs.com/package/lodash.debounce

madeofpalk 10y ago
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.

jdd 10y ago

You should check out https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/babel-plugin-lodash https://github.com/lodash/lodash-webpack-plugin https://github.com/lodash/lodash-webpack-plugin