3 ms·

Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies. First it was direct DOM manipulation without jQu

Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies. First it was direct DOM manipulation without jQuery getting in the way, now it's direct JS calls without a utility library getting in the way. The ecosystem really has come a long way. It's also worth noting that lodash lets you import individual functions, e.g. import throttle from 'lodash/throttle' so even when you do need a utility function you can avoid pulling the entire library into your code.

stolenmerch 4y ago
Looks like this will be removed in v5. "For example, throttle uses debounce internally. In a project using both methods from the main lodash package, throttle will import the same debounce module as any code that imports debounce directly, so only one copy of debounce will wind up in a webpack bundle."
- afavour 4y ago
  Looks like the v5 deprecation is only the separate modules. "lodash/throttle" loads throttle.js in the lodash package. "lodash.throttle" loads index.js in the lodash.throttle package. The latter is being deprecated but not the former.
CharlesW 4y ago
> Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies. Assuming you're working on commercial products, how do you decide when to move to new-ish native functions? For example, do you log feature detection for the function a month or two prior to the planned change?
- e1g 4y ago
  You probably have HTTP access logs and can use that to run your own calculations based on UserAgent and caniuse. We are in enterprise, and 90% of our users are on evergreen browsers, and the next 9% have a browser version from the last 18 months. For the last minority, we conditionally include a polyfill from polyfill.io “Browser support” is not an issue anymore unless you do something cutting edge, sell to regulated industries like healthcare, or serve many users in China/Africa et al.

stolenmerch 4y ago

Looks like this will be removed in v5. "For example, throttle uses debounce internally. In a project using both methods from the main lodash package, throttle will import the same debounce module as any code that imports debounce directly, so only one copy of debounce will wind up in a webpack bundle."

afavour 4y ago
Looks like the v5 deprecation is only the separate modules. "lodash/throttle" loads throttle.js in the lodash package. "lodash.throttle" loads index.js in the lodash.throttle package. The latter is being deprecated but not the former.

CharlesW 4y ago

> Having worked in the JS ecosystem for far too long now it's enormously satisfying to remove these dependencies. Assuming you're working on commercial products, how do you decide when to move to new-ish native functions? For example, do you log feature detection for the function a month or two prior to the planned change?

e1g 4y ago
You probably have HTTP access logs and can use that to run your own calculations based on UserAgent and caniuse. We are in enterprise, and 90% of our users are on evergreen browsers, and the next 9% have a browser version from the last 18 months. For the last minority, we conditionally include a polyfill from polyfill.io “Browser support” is not an issue anymore unless you do something cutting edge, sell to regulated industries like healthcare, or serve many users in China/Africa et al.