Only last week, one of our talented junior developers tried to convince me that utility libraries (in this case lodash or ramda) were worth including because they are tried and tested and have better code quality than anything you could write in a few minutes.
I raised three objections:
Many of those libraries have a track record of having had many exploitable vulnerabilities and bad code quality. Just because something is widely used doesn't mean it is secure and has good code quality. Internet Explorer was the most used browser at one point in history and some of us still remember... though I digress.
You often get a lot more than you think: let's take for example an isEmpty function - he actually brought it up in the discussion, which I am thankful about. In most cases you want to use it, you know exactly what type of value you are checking (if you are using TypeScript, you could even get it inferred if it is not already typed). In most cases, these are Objects, because in every other case, you wouldn't even consider isEmpty. There are a lot of checks for sets, maps, strings, etc., that you won't need for your use case.
Using these helpers can save time, but that time is only wasted if used to think about a solution before understanding the underlying problem. Especially if you are less experienced, I challenge you to try this: before you import a helper to write an easy solution, try to understand the problem and how your helper would be solving it (e.g. by reading its sources). Then, only if implementing the solution yourself will take more than twice as long as an npm install, should you add the extra dependency. Even if you don't change your behavior, you will at least have learned how those helpers are doing it.
TL;DR: When using external dependencies is merely a replacement for thinking about the underlying problem, the diagnosis of NIHS does not apply.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Only last week, one of our talented junior developers tried to convince me that utility libraries (in this case lodash or ramda) were worth including because they are tried and tested and have better code quality than anything you could write in a few minutes.
I raised three objections:
Many of those libraries have a track record of having had many exploitable vulnerabilities and bad code quality. Just because something is widely used doesn't mean it is secure and has good code quality. Internet Explorer was the most used browser at one point in history and some of us still remember... though I digress.
You often get a lot more than you think: let's take for example an
isEmptyfunction - he actually brought it up in the discussion, which I am thankful about. In most cases you want to use it, you know exactly what type of value you are checking (if you are using TypeScript, you could even get it inferred if it is not already typed). In most cases, these are Objects, because in every other case, you wouldn't even considerisEmpty. There are a lot of checks for sets, maps, strings, etc., that you won't need for your use case.Using these helpers can save time, but that time is only wasted if used to think about a solution before understanding the underlying problem. Especially if you are less experienced, I challenge you to try this: before you import a helper to write an easy solution, try to understand the problem and how your helper would be solving it (e.g. by reading its sources). Then, only if implementing the solution yourself will take more than twice as long as an npm install, should you add the extra dependency. Even if you don't change your behavior, you will at least have learned how those helpers are doing it.
TL;DR: When using external dependencies is merely a replacement for thinking about the underlying problem, the diagnosis of NIHS does not apply.