5 ms·

Pros and cons. Everything has them. I think the really big issue with all these package management solutions is how deep the dependency requirements go. One pa

by selykg 6y ago

Pros and cons. Everything has them. I think the really big issue with all these package management solutions is how deep the dependency requirements go. One package depends on another package that depends on 18 other packages, that depend on 30 other packages, and it's packages all the way down. No one is going to review all of those packages regularly. It's just not going to happen. Sure, it's less a problem for the big popular packages, but those big popular packages still depend on a lot of smaller packages and those smaller packages are extremely vulnerable due to sheer lack of eyes on it. Everyone always says "I won't use software that isn't open source because the code is in the open and vulnerabilities can be found" but the fact of the matter is someone has to be reviewing that code to find them. I'd love to better understand how many people are out there reviewing code as part of their process. I'll be it's a lot less than anyone would like.

mason55 6y ago
The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. It’s really just the consequence of asymmetrical outcomes. Most of the time it all just works and so if you don’t keep up you’re out of business. When something goes wrong the whole world is exposed. I guess with npm you do have the additional wrinkle that much of it is outside the std lib which increases risk a bit.
- umvi 6y ago
  > The alternative is to develop the entire stack in house Maybe now because everyone is entrenched, but the alternative could have been to offer a robust "standard library" in the first place that lets you cover 90% of developer's use cases without needing external packages. See: Java, C/C++, Go, Python... Only JavaScript seems to be a special snowflake where doing even the most basic tasks requires downloading 50 packages.
  - Karunamon 6y ago
    I'm not super familiar with the JS ecosystem, but isn't Node unique in that it tends to have packages for things that arguably have no business being their own dependencies? leftpad comes to mind.
  - pdpi 6y ago
    For all the reasons you might criticise JavaScript, that’s one of the least reasonable. Python is specifically known as a “batteries included” language, and Go has stdlib support for the core use cases the language is designed for. I wouldn’t say that C++ or Java have particularly rich standard libraries outside of IO and common data structures, and C is downright anaemic.
    - dtech 6y ago
      JVM/Java has an extensive stdlib, including a decent DNS/IP resolution library that this package contains a vulnerability in. It also has one of the best date/time libraries I've ever seen, while that it external in nearly all languages for example.
    - jjav 6y ago
      > I wouldn’t say that C++ or Java have particularly rich standard libraries The Java standard library is about as rich as it gets. I rarely ever have had to use external dependencies when working on Java projects.
  - nemothekid 6y ago
    In your examples, only Java and Go have robust standard libraries and both are essentially corporate programming languages. The claim that C has a safe and/or robust standard library is very bizarre. Python only got there after years of community development (Python is 30 years old, Node is 11), and even today I wouldn't consider it particularly high quality.
- jjav 6y ago
  > The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. First, you'd never develop everthing in house. But there is a middle ground between selecting a few very well known dependencies that are nowhere near practical to do in-house (e.g. OpenSSL) and the extreme of the npm world where every one-liner is a package. Another great solution is to select a language with a rich well-tested standard library. Rely on the standard library for 80% of your utility class needs. Complement with a small number of well-known external libraries for another 20% and the remaining 10% build in-house. If one can't, off the top of their head, name every external dependency and where they come from, that's too many.

by selykg 6y ago

mason55 6y ago

The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. It’s really just the consequence of asymmetrical outcomes. Most of the time it all just works and so if you don’t keep up you’re out of business. When something goes wrong the whole world is exposed. I guess with npm you do have the additional wrinkle that much of it is outside the std lib which increases risk a bit.

umvi 6y ago
> The alternative is to develop the entire stack in house Maybe now because everyone is entrenched, but the alternative could have been to offer a robust "standard library" in the first place that lets you cover 90% of developer's use cases without needing external packages. See: Java, C/C++, Go, Python... Only JavaScript seems to be a special snowflake where doing even the most basic tasks requires downloading 50 packages.
- Karunamon 6y ago
  I'm not super familiar with the JS ecosystem, but isn't Node unique in that it tends to have packages for things that arguably have no business being their own dependencies? leftpad comes to mind.
- pdpi 6y ago
  For all the reasons you might criticise JavaScript, that’s one of the least reasonable. Python is specifically known as a “batteries included” language, and Go has stdlib support for the core use cases the language is designed for. I wouldn’t say that C++ or Java have particularly rich standard libraries outside of IO and common data structures, and C is downright anaemic.
  - dtech 6y ago
    JVM/Java has an extensive stdlib, including a decent DNS/IP resolution library that this package contains a vulnerability in. It also has one of the best date/time libraries I've ever seen, while that it external in nearly all languages for example.
  - jjav 6y ago
    > I wouldn’t say that C++ or Java have particularly rich standard libraries The Java standard library is about as rich as it gets. I rarely ever have had to use external dependencies when working on Java projects.
- nemothekid 6y ago
  In your examples, only Java and Go have robust standard libraries and both are essentially corporate programming languages. The claim that C has a safe and/or robust standard library is very bizarre. Python only got there after years of community development (Python is 30 years old, Node is 11), and even today I wouldn't consider it particularly high quality.
jjav 6y ago
> The alternative is to develop the entire stack in house. Unlikely that you’ll do any better and meanwhile your competitors will pass you by. First, you'd never develop everthing in house. But there is a middle ground between selecting a few very well known dependencies that are nowhere near practical to do in-house (e.g. OpenSSL) and the extreme of the npm world where every one-liner is a package. Another great solution is to select a language with a rich well-tested standard library. Rely on the standard library for 80% of your utility class needs. Complement with a small number of well-known external libraries for another 20% and the remaining 10% build in-house. If one can't, off the top of their head, name every external dependency and where they come from, that's too many.