4 ms·

Libraries like lodash/underscore don't get popular for no reason. The API matters, and readability matters. Sure, you can do these things without the library, b

Libraries like lodash/underscore don't get popular for no reason. The API matters, and readability matters. Sure, you can do these things without the library, but the readability suffers. Adding in the ability to chain these calls into a nice little readable "paragraph" of small single step data changing functions, there's significant value in the underscore and similar compatible libraries.

mlajtos 4y ago
> The API matters, and readability matters. Exactly, lodash should be part of the language. https://github.com/mlajtos/es1995 https://github.com/mlajtos/es1995
lcvriend 4y ago
I am sure you are right. However, this does look very useful to me. I am not a professional js developer but I do like to build dinky websites. I generally prefer not to bother with build steps or dependencies. For me it's preferable to have my own implementation of a function within the file or project I am working in. That way I can directly inspect what the function is doing, which is "more readable" to me. Moreover, sometimes I need functionality that is similar but just a bit different from something that lodash does. This seems like a good resource to check for inspiration.
SkyPuncher 4y ago
Lodash also handles "bad-types" in really graceful ways. In fact, it's almost the primary reason I use it. For example, if you have a nullable array. In plain JS, you have to check the presences of the array, then run `find` (or whatever function). Lodash simply treats it like an empty array - returning nothing. This is particularly handy in React where it creates clutter to have to check for the empty state.
- shortcake27 4y ago
  In your nullable array example, you could just use optional chaining. There’s no need for lodash. I personally feel this type of ultra-defensive programming where all types are assumed bad only harms you long run, adding complexity where it isn’t necessary to solve problems that don’t exist, and swallowing errors making it harder to debug. Exceptions exist for a reason. When I switched to TS it was a great incentive to ditch lodash because it was munging all my types. This in turn simplified my code as it made me aware of unnecessary guards, coercions, and errors that lodash was swallowing.

mlajtos 4y ago

> The API matters, and readability matters. Exactly, lodash should be part of the language. https://github.com/mlajtos/es1995 https://github.com/mlajtos/es1995

lcvriend 4y ago

I am sure you are right. However, this does look very useful to me. I am not a professional js developer but I do like to build dinky websites. I generally prefer not to bother with build steps or dependencies. For me it's preferable to have my own implementation of a function within the file or project I am working in. That way I can directly inspect what the function is doing, which is "more readable" to me. Moreover, sometimes I need functionality that is similar but just a bit different from something that lodash does. This seems like a good resource to check for inspiration.

SkyPuncher 4y ago

Lodash also handles "bad-types" in really graceful ways. In fact, it's almost the primary reason I use it. For example, if you have a nullable array. In plain JS, you have to check the presences of the array, then run `find` (or whatever function). Lodash simply treats it like an empty array - returning nothing. This is particularly handy in React where it creates clutter to have to check for the empty state.

shortcake27 4y ago
In your nullable array example, you could just use optional chaining. There’s no need for lodash. I personally feel this type of ultra-defensive programming where all types are assumed bad only harms you long run, adding complexity where it isn’t necessary to solve problems that don’t exist, and swallowing errors making it harder to debug. Exceptions exist for a reason. When I switched to TS it was a great incentive to ditch lodash because it was munging all my types. This in turn simplified my code as it made me aware of unnecessary guards, coercions, and errors that lodash was swallowing.