3 ms·

Lodash has two values, a bunch of utility functions and it works cross browser. The most common utility functions are now standard issue in es6+. And a transpil

Lodash has two values, a bunch of utility functions and it works cross browser. The most common utility functions are now standard issue in es6+. And a transpilation build process is a superior way of dealing with cross browser incompatibilities. Babel + browserlist + caniuse all work seamlessly to ensure you only have the polyfills and browser support you need, vs the one-size-fits-all approach of lodash. There's probably a handful of functions in lodash that are still useful but why take on the security risk and maintenance of another package dependency if you can just copy a couple ten-liners into your own utils folder? It's not like the world is going to come up with a more performant debounce anytime soon. I guess lodash also relies on jquery which is in the same boat. es6+ has stolen a lot of its thunder and target-aware transpilation is a better approach to cross browser support

heckanoobs 8y ago
I have more nuanced takes on lodash too but I'm putting them in another reply to separate them from the big picture stuff I already mentioned. Lodash also differs from the standard lib's implementation, notably it's too permissive. Take this example: const uhoh = null _.forEach(uhoh, () => {}) uhoh.forEach(() => {}) lodash's forEach has no problem running on a falsey value (it gives you back the value) whereas standard lib leads you to a TypeError. Two thoughts here. The standard lib forces the programmer to think more about types, which is a good thing. Second is that lodash's more loosey goosey approach acts as vendor lock-in. In two years, when there's 60 lines and 3 files of separation btwn uhoh's assignment and the _.forEach invocation, you won't know whether it's expected to be null or not. So you won't know if you should replace the code with uhoh.forEach(...) or (uhoh || []).forEach(...)

heckanoobs 8y ago

I have more nuanced takes on lodash too but I'm putting them in another reply to separate them from the big picture stuff I already mentioned. Lodash also differs from the standard lib's implementation, notably it's too permissive. Take this example: const uhoh = null _.forEach(uhoh, () => {}) uhoh.forEach(() => {}) lodash's forEach has no problem running on a falsey value (it gives you back the value) whereas standard lib leads you to a TypeError. Two thoughts here. The standard lib forces the programmer to think more about types, which is a good thing. Second is that lodash's more loosey goosey approach acts as vendor lock-in. In two years, when there's 60 lines and 3 files of separation btwn uhoh's assignment and the _.forEach invocation, you won't know whether it's expected to be null or not. So you won't know if you should replace the code with uhoh.forEach(...) or (uhoh || []).forEach(...)