Because you need to trust 1000 different people.

Again, it's not about the number of people, is it? You don't have 1000 top level dependencies, so you're not trusting 1000 entities. If you're really talking about people, companies that produce libraries have hundreds of employees - do you "trust" them all? No, what you're talking about is establishing a web of trust, and you can do that in JS as well. Use a framework, use a library that combines a set of tools together. There's nothing particularly different about JS in this regard - there are plenty of large-scale development shops(Google, Facebook, Mozilla, Yahoo, Netflix..) which offer code, alongside a healthy open source community. You choose what to use.

1000 transitive dependencies is not the same as a single dependency with 1000 employees. For one, I highly doubt each employee can `npm publish`.

Consider the destructiveness of someone malicious befriending the left-pad developer, taking the project over, and doing a malicious push.

I'd say the scale of the potential destruction in so many tiny, few-eyeballed modules is unique to the npm ecosystem for better or worse.

It's one of the security downsides of the ecosystem especially in the online casino space where I work. For example, getting an online casino's `npm ls` (full depth) would be a good place to start.

The scale of transitive deps we're talking about when compared to any other ecosystem is quite excessive, but also just how tiny many of those deps are.

> Consider the destructiveness of someone malicious befriending the left-pad developer, taking the project over, and doing a malicious push.

Not different from someone befriending a corporate employee and asking them to insert some malicious code into the codebase. You still rely on a web of trust - in the company's case, the code reviewers, in the open source example, the maintainers of the libraries that use left-pad. I don't think this argument really holds, I don't know what you're comparing it against that's different.

We'll have to agree to disagree if you see equivalence there.

Even the smallest transitive dependency in our largest dependency graph in the Java ecosystem isn't someone's 6-liner afternoon project.

I think the ease of publishing + ecosystem of small modules is a good thing, it just has what we consider an ecosystem-level security trade-off that matters for some applications.

The corporate employee is likely incentivized by a contractual obligation not to deliberately screw their employer over. There is a web of trust, sure, but don't pretend that it's somehow equivalent to betting that some rando on the internet doing whatever they feel like with their three line repo won't break your code.