3 ms·

Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point

Importing anything into a project, no matter how small, creates a new dependency. Any additional dependency introduces, among other costs: * a potential point of failure * a potential source of security vulnerabilities * a potential legal liability and maybe some licensing constraints, and * an additional aspect that needs to be maintained indefinitely and understood by any future developers. Accepting all of this just to save a few minutes writing a simple function and maybe a test or two doesn’t scale very well. At best, it is replacing a superficial problem with a deep set of extra and ongoing responsibilities. This is before we consider the time required to find and evaluate a suitable package, and even then, there is no guarantee that some random small NPM package from a source you’ve never heard of will be any better than what you’d have written yourself if you’re a halfway decent programmer.

pojzon 8y ago
Unfortunety the moment the person you explained that to understood it. 50 new young developers joined the bandwagon of "download everythink, think later".. Thats the issue with frontend.
winstonewert 8y ago
But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself. In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixed by other people.
- Chris_Newton 8y ago
  But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. If those inherent risks are also significant and you can mitigate them by importing a good implementation of the required functionality instead of building your own, that can be a trade-off worth making. It would rarely be a good idea to use a home-grown encryption algorithm, for example. However, if we’re talking about simple functionality that you could write yourself in minutes anyway and where you would have to try quite hard to create a significant vulnerability or to need much ongoing maintenance, the costs introduced by importing the functionality instead will often be disproportionate.
  - winstonewert 8y ago
    > Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. Why? What is different about an external dependency that creates this risks in excess of writing it myself? To me, these risks all seem less when importing then writing it myself. No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it.
    - Chris_Newton 8y ago
      Why? What is different about an external dependency that creates this risks in excess of writing it myself? You seem to be answering your own question there: the extra risk is because you aren’t writing it yourself. The extra risk is because you are trusting an external source to provide what it says it will and that whatever it provides will then work as described. As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs. No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it. I can see no basis for that assumption in the world of JS and NPM. Anyone can set up an NPM account and then push code for public consumption. Giants like react have been brought down by tiny packages like left-pad. And yet, I could have written the code for left-pad, complete with a little test suite, in less time than it has taken me to write this HN comment, and probably so could a million other people. How much collective development time do you think was lost because no-one at Facebook actually did?
      - winstonewert 8y ago
        As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs. Fair enough, most of those are legitimately risks of external code that doesn't apply to internal code. However, I object to object that nobody writes bug-free code so the possibility of my chosen package having bugs isn't such a case. > I can see no basis for that assumption in the world of JS and NPM I overstated my point there. > Giants like react have been brought down by tiny packages like left-pad. Its a nit-pick, but react wasn't broken by left-pad. Babel was broken which is almost always used with react.

pojzon 8y ago

Unfortunety the moment the person you explained that to understood it. 50 new young developers joined the bandwagon of "download everythink, think later".. Thats the issue with frontend.

winstonewert 8y ago

But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. These are costs which, for the most part, apply to code whether you import it or write it yourself. In fact, the imported code is arguably better in many cases because if there is a problem in my code it only gets fixed if I fix it. At least sometimes, problems in my imported code gets identified and fixed by other people.

Chris_Newton 8y ago
But code I write is also a potential source of failures, security vulnerabilities, and future maintenance burden. Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. If those inherent risks are also significant and you can mitigate them by importing a good implementation of the required functionality instead of building your own, that can be a trade-off worth making. It would rarely be a good idea to use a home-grown encryption algorithm, for example. However, if we’re talking about simple functionality that you could write yourself in minutes anyway and where you would have to try quite hard to create a significant vulnerability or to need much ongoing maintenance, the costs introduced by importing the functionality instead will often be disproportionate.
- winstonewert 8y ago
  > Perhaps, but the mere act of having an external dependency creates all of those liabilities on a significant scale in addition to any risks inherent in whatever functionality is being implemented. Why? What is different about an external dependency that creates this risks in excess of writing it myself? To me, these risks all seem less when importing then writing it myself. No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it.
  - Chris_Newton 8y ago
    Why? What is different about an external dependency that creates this risks in excess of writing it myself? You seem to be answering your own question there: the extra risk is because you aren’t writing it yourself. The extra risk is because you are trusting an external source to provide what it says it will and that whatever it provides will then work as described. As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs. No matter how crappy the module I find is, its gone a lot more testing and review than whatever code I'd write to replace it. I can see no basis for that assumption in the world of JS and NPM. Anyone can set up an NPM account and then push code for public consumption. Giants like react have been brought down by tiny packages like left-pad. And yet, I could have written the code for left-pad, complete with a little test suite, in less time than it has taken me to write this HN comment, and probably so could a million other people. How much collective development time do you think was lost because no-one at Facebook actually did?
    - winstonewert 8y ago
      As we have seen all too many times, these things are not guaranteed. The repository can be down. Semantic versioning might not be specified correctly. Packages might be transferred to a new maintainer who then abuses them to deliver malicious payloads. Or the package you pick might simply have bugs. Fair enough, most of those are legitimately risks of external code that doesn't apply to internal code. However, I object to object that nobody writes bug-free code so the possibility of my chosen package having bugs isn't such a case. > I can see no basis for that assumption in the world of JS and NPM I overstated my point there. > Giants like react have been brought down by tiny packages like left-pad. Its a nit-pick, but react wasn't broken by left-pad. Babel was broken which is almost always used with react.