4 ms·

Why does NPM always seem to have this kind of issues? Why do we rarely hear about similar problems with Maven Central, for example?

• carlmr 2y ago
  Biggest target had biggest number of issues?
• _mlbt 2y ago
  I think a lot of it comes down to attack surface. JavaScript famously has a very limited standard library, so it is very common to pull in massive dependency chains of modules containing trivial functionality. Contrast this to Java, C#, and Python, where you can write robust applications with just the standard libraries.
  • thewebguyd 2y ago
    Yep. See left-pad from from 2016. Something so trivial it was basically part of every other major language's standard library (and it is now in JS, but wans't at the time). Other gems exist in the NPM world like is-odd, isarray, and is-negative-zero. The whole ecosystem developed this absurd culture of micro-packages that all do something insanely trivial that's built-in to pretty much every other language. All of it is a result of trying to force the web into doing things it was never really designed for or meant to do. Browsers were never supposed to be full application runtimes, and yet we (as an industry) keep doubling down on it
    • whstl 2y ago
      The culture of micro-packages is mostly pushed by people with financial interests. The modus operandi is to add a semi-useful package to a popular project, and then divide said project into other sub-projects just to bump the numbers. Then those individuals start claiming that they have "25 packages that are foundational to the web infrastructure", while in fact it's just a spinner that has 24 dependencies, some of those being one-liner packages. Parallel to that we also have things like Babel, which has hundreds of packages, a huge chunk of them being almost empty and only triggering flags in the core package.
    • yupyupyups 2y ago
      >Browsers were never supposed to be full application runtimes, and yet we (as an industry) keep doubling down on it Web technologies are multi-platfrorm, widely accessible, has an unmatched UI API, has great tooling and a large ecosystem. It's the path of least resistance. Contrast this with something like Qt, which is an absolute pain to compile and is riddled with bugs. It's GUI library is mature, but nowhere near the web. Time is money, and developers are many times more expensive than the extra cpu cycles the web consumes.
      • dgfitz 2y ago
        > Contrast this with something like Qt, which is an absolute pain to compile and is riddled with bugs. Compiling qt is a choice, there are many, many ways to get precompiled libs. Also, it is only hard to compile if you’re not familiar with ./configure, it is actually absurdly easy to compile and link against qt. As for the bugs thing, sure, qt has bugs. So does _all other software_ and this is a very strange argument to make on your end.
        • yupyupyups 2y ago
          I would say, for serious development you should know how to compile the thing. Because some bugs cannot be worked around without actually patching the library. Qt has many dependencies, and it's not always clear which libraries are needed for any particular functionality. Try compiling the documentation and setting up the code examples properly in Qt Creator, it's not that easy and the instrucrions on how to do that are incomplete. >As for the bugs thing, sure, qt has bugs. So does _all other software_ and this is a very strange argument to make on your end. Most mature software do not expose their bugs early to their users. Qt has occationally some really silly bugs that pop up across versions that simply shouldn't be there if you have proper QA. When they kept away LTS updates from non-paying users, this I would argue risked becoming a bigger issue. I don't want to talk bad about Qt, it's actually a really awesome library. But it has its quirks that are timeconsuming to work around, which can hinder wider adoption. That was all I was trying to say. Note, I would actually recommend it if someone is interrested in building native applications with good performance, and is comfortable with C++, alternatively I would suggest a Python wrapper such as pyside to mitigate many of the issues I was talking about.
    • pjc50 2y ago
      > Browsers were never supposed to be full application runtimes Unfortunately all the proprietary OS vendors want to prevent the development of fully portable runtimes, so we've ended up where the browser is the only fully portable application runtime.
  • marginalia_nu 2y ago
    To be fair Java has a pretty large package ecosystem as well, including a significant number of dependencies. Though the culture is very different, and you generally tend to avoid dependencies if possible. The idea of pulling in a package for testing whether a number is even or odd is incredibly foreign.
• johnny22 2y ago
  not sure about java land, but we have seen this on pypi and i think even on rubygems.
• robinsonb5 2y ago
  Perhaps because nowhere else has one package for every 2,972 humans on planet Earth?
• feross 2y ago
  Great question. A few reasons: – The JavaScript ecosystem moves faster — way more packages, more frequent updates, and more transitive dependencies (avg 79 per package). – npm has lower barriers to publishing, so it’s easier for malicious actors to get in. – Java developers often use internal mirrors and have stricter review processes, while npm devs tend to install straight from the registry. – But to be clear, supply chain attacks do happen in other ecosystems — they’re just underreported. We’ve seen similar issues in PyPI, RubyGems, and even Maven. JavaScript just happens to be the canary in the coal mine.
• rvz 2y ago
  The Javascript ecosystem is the problem and is completely immature by design.