There's been a lot of whining about “too many dependencies” in applications. This goes along with a more general trend of complaining about how borked this or that platform is.
Here's a quote from a recent example:
As I sit here, looking at a stack trace of my coffee-script code, which runs through a ruby-based javascript interpreter sitting on top of the asset pipeline which runs through rails and spits out an error via a gem which globally hooks into the exceptions bubbled up from the depths of hell, and yet the stack trace can only give me a vague file reference and the type of error it is, but not actually point me at the actual error at all, and this ajax call has no good way of debugging itself besides injecting a debugger into the runtime and breaking and poking around, and the myriad of gems we use all seem to be conflicting into —
The idea seems to be that if the author was only using a better development platform (in this case, Rails is in the cross-hairs) life would be so much better.
I have bad news, though. The problem is that you are solving hard problems and you probably need to get better at doing your job.
I have a love/hate relationship with my fellow developers. On the one hand, I believe they are often exploited by non-technical executive leadership, through a wide variety of tactics ranging from coercive optimism to manipulative word choices (“sprint”). On the other hand, we get paid well exactly because not everyone can do what we do. That is, solve hard problems. So complaining about how hard the problems are is pretty self-defeating. It's like movie stars complaining about paparazzi. If programming wasn't hard, you'd probably be a barista.
In the example above, if your first line of defense is stack traces you're doing it wrong. That should be the exception (get it?) not the rule. Second, part of the reason for that is because stack traces are always tricky. Try debugging a stack trace in assembly sometime. And, yes, that's a thing developers do, even today, which you might not have known because they aren't whining about how hard it is.
Back to the “too many dependencies” business. If you're among those complaining about this, you're in the wrong business. And you're in denial. Before you even start coding, you're already depending on thousands upon thousands of other libraries in the form of the operating system, database, and the language platform upon which you will run your application. The few dozen modules that it loads barely even rates.
And what's the alternative here? I've literally seen developers saying, “this modules is only 10 lines of code, just copy and paste it!” Sure by all means, let's copy and paste code. Perhaps you could argue that small bits of code might make more sense in a more general purpose library, but it doesn't make much difference.
Some of you are screaming dependencies! right now, and you're wrong. To begin with, if someone makes a breaking change it won't make any difference how big or small the library is, it will still be a breaking change.
If you're really worried about that, freeze the version you depend upon. Yes, it's possible in many package managers to replace previously published code. But, first, that's a package manager issue, and, yeah, package managers aren't perfect. If you don't like that, write a better one. And second, this is a pretty rare situation in modern package managers. Programming is hard and sometimes things go wrong. One day, all these problems will be solved, but you were apparently born too early for that.
You know what we do when we have a tedious, repetitive task? We automate it! Because we're programmers! Package managers effectively automate copying-and-pasting code. And if you think you're incapable of making backwards incompatible breaking changes in your own code, well, good for you, I guess?
In any event, the solution is not to go back to copying-and-pasting code. Decades of collective experience has led us, as an industry, to the conclusion that libraries and modules are the best way to deal with code reuse. The operating system you're running, you're mobile apps, you're programming editor, the programming language platform you use, they are all built using libraries and modules. Don't decide that you know better just because you had one bad day with an unlikely edge-case in your imperfect-but-also-free package manager.
A lot of this comes from following best practices, also known as learning how to do your job. How's your test coverage look? High coverage can help you avoid those nasty stack traces. How does your continuous integration process look? That, in combination with that high-test coverage will identify breaking changes for you before you go to production! Isn't that nice?
Good design and architecture is just as important, if not more so. For example, a good design minimizes dependencies for you before you ever deploy your application. That practice goes by a variety of names: encapsulation, loose coupling, and so on. But good design is also hard. You need to experiment and iterate, until you get your design right, instead of pushing your code out the door with a design that will lead to problems later, (for which you will blame your tools).
The fact that I see more complaining about the tools (package managers, language platforms) than I do about how hard it is to design well or get good test coverage or implement a good CI process is a red flag.
If you do those things, you won't be complaining about stack traces or flawed package managers any more. Of course, then you'll be complaining about different things, but, still, that will be a step in the right direction.