Evaluating a framework by the number of files its dependencies are broken into is a a pretty poor measure of quality.
I believe that creating a module without relying on other modules will likely lead to reinventing the wheel. Well, lots of wheels.
However, that might still be fine. But what about that one corner case you missed? It might already be solved in a third-party module that focuses on one thing only.
It's really not that bad to try and use specialized modules as much as you can. You can benefit from other people's cleverness and focus on more relevant work.
Yes, there will probably be a lot of on-disk overhead. But is that really relevant today?
If there is a well written, well tested, and widely used micro-library out there that does one thing and does it very well, why not use it?
Even if you think you can re-implement it in 5 minutes, will yours be as fast? Will yours be as well tested? Will yours have an interface that many other developers already know and use?
Sometimes reinventing the wheel is needed, but most of the time using a well working wheel that someone else made is the best choice.
Because every dependency comes with a cost. First of all, it needs to be available and the author might decide to pull it - maybe not from npm, but from github. Second is a matter of trust: Someone just needs to take over the left-pad authors npm account an all of a sudden he can inject arbitrary code into all projects using the dependency. I'd bet that 90% of folks don't even bother to check the left-pad code. So basically you need to trust each and every author of dependencies that they're benevolent and competent, that is: They don't drop the ball, get hacked, loose access, ... And that task gets harder and harder the more dependencies you have to vet. In a lot of instances just inlining the code would be better. A larger stdlib that can be selectively included would be better. It's a tough problem and npm just sits on an extreme end of the scale.
Bundling to me is such a sledgehammer solution. Yeah, it can somewhat prevent many of those issues, but it also comes at a pretty large cost.
* it leads to code duplication
* it can ruin the performance of tree-shaking and minification systems
* it prevents you from swapping out a small module with another globally
* it makes it harder to inspect and debug the code that you have installed in the node_modules directory
* it makes it harder to verify that the code on your machine is the same as the source code
* the bundler can introduce bugs into the source code
* The package now needs to maintain a build step and needs to maintain a separate source and "binary"
And more. Plus, in the end you might not even be helping anything. A big repo like lodash can have just as many contributors as tons of little dependencies, and big repos aren't immune to the org running it going belly up.
I guess I see those problems as more of a "large amount of code" problem instead of a "large amount of dependencies" problem.
Neither did I deny that inlining everything comes at a cost as well, so the goal is to find a good point on the scale. I was just pointing out that having tons of small dependencies is not free of cost.
There are too many implementations (by design) and the language is such a "mutt" of designs that it will never happen.
I personally don't think that's a bad thing, but it is different to how many languages work.
If there are N ways to write a program, M of which are security hazards, it's better to have M/N of all programs exposed to risk than have a M/N chance that all programs are borked.
"Reinventing the wheel" is a leaky cliché: the problem at hand isn't that people would independently try to come up with the solution to a simple problem (rolling something down a hill), but that the instantiations of a solution would be irrevocably linked, such that one flat tire stops all cars.
What's more - jesus, go outside, look at how many kinds of skateboard wheels, car wheels, bike wheels you see in five minutes time.