Why does NPM always seem to have this kind of issues? Why do we rarely hear about similar problems with Maven Central, for example?
Contrast this to Java, C#, and Python, where you can write robust applications with just the standard libraries.
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
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.
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.
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.
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.
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.
– 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.