[Xylakant]

> 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?

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.

[Klathmon]

I still maintain that those problems can be solved with better tooling and package management rather than "bundling" dependencies.

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.

[Xylakant]

I wasn't talking about bundling but rather about something like C glibc or rusts stdlib. Having a solid stdlib that covers for example string padding can at the same time minimize code duplication and number of dependencies.

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.

[Klathmon]

Fair enough, but with a language like Javascript a large standard library will never be a reality.

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.