[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.