> Seriously? This is what you're going with? We're talking about very simple, elementary programming. To be worried about maintaining code that you learn how to do in the first few classes of any programming 101 class is absolute insanity.
Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
> Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
So figure out a process and resolve that, once and for all. There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
> Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you?
That's exactly why people were depending on this library.
> Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
I'm sorry but that is just a horrible way to look at programming.
You shouldn't NEED to go out and look for an already done solution if it's elementary and takes minutes, if that, to write. Ever.
This is just sloppy.
> So figure out a process and resolve that, once and for all.
Tell yourself that; that was simply a counter argument to your false claim. Regardless it's fixable.
> There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
This doesn't even make sense. What are you trying to convey here? The more dependencies you can cut out the more reproducible your builds will be. Period. Which is important when you're dealing with code that gets rapidly deployed to many production boxes.
> That's exactly why people were depending on this library.
If using left pad gave them time back because the original author could do it better, faster and cheaper...I'm not sure programming is the right type of work for these people.
What's next, are you going to outsource all your for and while loops to a module? You know, so you have less things to "maintain"?
> You shouldn't NEED to go out and look for an already done solution if it's elementary and takes minutes, if that, to write. Ever.
If writing it would take minutes and adding the dependency would take seconds, add the dependency. And how long it takes to look for is beside the point - code is read more than it's written, so how long it takes to read is much more important.
> This doesn't even make sense. What are you trying to convey here? The more dependencies you can cut out the more reproducible your builds will be. Period. Which is important when you're dealing with code that gets rapidly deployed to many production boxes.
No, look, if you have some kind of problem where dependencies maker your builds unreproducible or break your deployments, you need to fix that problem. If you have that problem when you have 100 dependencies, you're still going to have that problem when you have 90 dependencies. Unless you're going to cut every dependency, cutting dependencies is not the way to fix that problem.
> What's next, are you going to outsource all your for and while loops to a module? You know, so you have less things to "maintain"?
for and while probably should be ordinary functions (smalltalk style) and probably should be in a library somewhere rather than having everyone reimplement them, yes. Almost all languages have a for or while in their standard library so I don't know what you're really saying?
Every line is a maintenance burden - just reading and understanding the code is what takes most of the time. Lines of code (and notably not any measure of "complexity" of those lines that's been tried) is the one thing that correlates with bug rates.
> Can't resolve them if the module disappears or is replaced with a malicious module. Nor if you or npm are having connectivity issues (which, on the npm side, happens very frequently).
So figure out a process and resolve that, once and for all. There's no point just cutting 10% (say) of your dependencies and hoping that you won't encounter the problem on your more important dependencies.
> Use the tools for the job they were meant to be used for. Need a dependency because someone can do it better / faster / cheaper then you?
That's exactly why people were depending on this library.