Come to think of it, the shortcoming of the description explains a lot of things about the current state of the JavaScript ecosystem.
Come to think of it, the shortcoming of the description explains a lot of things about the current state of the JavaScript ecosystem.
Many large, mature, and solid packages could have long histories of resolved CVEs.
Big systems have big surfaces, no matter what quality they are.
Dependency chains may be more of an issue. I think several of the last few big exploits have been compromises in fairly small packages, that were incorporated into larger ones.
Then, there's the "Bro Coefficient." Who wrote the package should count for a lot.
I'd trust a package written by "linus.torvalds," a lot more than one written by "L33tCoder420LOL," even if the Web site is super-sexy, and it has a gazillion GH stars.
Here, FTFY.
IOW, having a package manager in your programming language is a boon and a curse, but more of a latter. People just add a single line to their dependency list, and pull in the literal world. As long as their code runs the way it should, nobody, I mean, nobody cares.
This is a huge problem.
So do you prefer the situation in c++ where you just add one dependency, like "boost" or "Qt" and it still pulls in 15M lines of code but now it's just "one" dependency instead of 150?
On the other hand, you can introduce Qt modularly, so you don't have to import all of them. Same for Boost, though I don't use either.
I write Go and use Uber's zap for logging. It pulls in uncomfortable amount of code, too. Until I can find something better, I'll continue using it, but I'm not comfortable with it.
However, in C++ land, I was able to use standalone libraries like Catch or Eigen which were big, but not unwieldy, and Eigen is also as modular as Boost. So you know what you include and what you do at the end of the day.
I'm a big fan of standalone source code repositories which vendor minimum number of libraries (which I strive to develop, too). You need GCC and glibc only. Just make it, use it. "No hidden fees, no games", I may say.
Boost and Qt are very solid systems. They have well-deserved, excellent reputations. In order for this tool to be useful, it would need to have a “reputation score,” that relies on more than GH stars and social media buzz.
That said, I am not a fan of doing something like adding 1MB to a page load, so you can animate a button press; even if the dependency is reputable.
Sometimes, it makes more sense to reinvent the wheel, as opposed to bringing in an 18-wheeler.
Even ignoring the fact that no one forces you to add whole Qt to your project, do not compare Qt, which is a battle-tested, long-lived framework, developed and maintained for decades by the company that also provides commercial support for it, with a bucket of intermingled crap sourced from random repositories across the internet.
The compile might take a while, but the resulting binary may not be as big as you think.
This does not apply, however, to interpreted languages, like JS.
Not sure about "JIT" languages, though, like Python and PHP.
The difference is that with Go or Python you can, if you decide to, do quite a lot without either pulling random stuff from the internet or making your own implementation from scratch, due to extensive standard libraries.
Although it’s not so much Python that’s influencing Node.js but more like Deno and Bun that try to include everything but the kitchen sink.
To download the free Springer books during COVID.
I mean, ouch.
P.S.: If you like your eyes, please don't look at AI stacks.
the land of spherical cows...
reminds me of https://www.folklore.org/Negative_2000_Lines_Of_Code.html