4 ms·

The problem is the number of dependencies and the number of people you are (implicitly) trusting by using those dependencies. It's an overwhelming engineering

The problem is the number of dependencies and the number of people you are (implicitly) trusting by using those dependencies. It's an overwhelming engineering burden for those industries that are required to do that type of 3rd-party software auditing. When I use Java, I can trust - at an organizational level - large blocks of 3rd-party code (e.g. Spring, Java SDK) and may even be able to get them to assume some liability via agreement if their repositories for their libraries are breached and malicious code is injected. Additionally, because those libraries do so much, I require many fewer other 3rd party libraries that I'm required to audit. When I use JavaScript, I don't necessarily get those advantages. (NodeJS on the server side has an SDK, so this point does not apply there, so this is mostly directed at browser UI development.) Sure, we may use a framework like Angular, but I don't necessarily have confidence that Google has audited the 600+ transitive dependencies that the Angular team has pulled in. Because of this, I don't think that Google is prepared to assume liability in the face of malicious software injection, which means (in industries requiring audits) that we need to track down each one of those 600+ transitive dependencies and audit each one of them.

Klathmon 8y ago
It's less about the number of "dependencies" and more about the raw amount of code you need to audit. If you are capable of auditing 1 100k loc package, why aren't you capable of auditing 100 1k loc packages? Once you have audited a specific version, you can either vendor your dependencies (which I always encourage), or at the very least can lock all transitive deps down which both npm and yarn do by default now. If you vendor your deps, upgrades/changes are as easy to audit as a single project as you can get a diff of what changed right there in your own system. Now I'll agree that auditing any large amount of code is extremely difficult, but it's not a problem you can solve by switching to another ecosystem, at best you'll just move most of the code outside the realm you decided you need to audit.
- stefanfisk 8y ago
  Auditing doesn’t necessarily mean a full code review. For 10 large frameworks doing random checks might be enough for most use cases, but the equivalent method would require a lot more time for 1000 small libraries.

Klathmon 8y ago

It's less about the number of "dependencies" and more about the raw amount of code you need to audit. If you are capable of auditing 1 100k loc package, why aren't you capable of auditing 100 1k loc packages? Once you have audited a specific version, you can either vendor your dependencies (which I always encourage), or at the very least can lock all transitive deps down which both npm and yarn do by default now. If you vendor your deps, upgrades/changes are as easy to audit as a single project as you can get a diff of what changed right there in your own system. Now I'll agree that auditing any large amount of code is extremely difficult, but it's not a problem you can solve by switching to another ecosystem, at best you'll just move most of the code outside the realm you decided you need to audit.

stefanfisk 8y ago
Auditing doesn’t necessarily mean a full code review. For 10 large frameworks doing random checks might be enough for most use cases, but the equivalent method would require a lot more time for 1000 small libraries.