That's because the web dev ecosystem at one point decided, that libraries that only offer very minute functionality are acceptable as well as adding 20 of them to your project.
Examples like isEven or left Pad come to mind, which have such high proliferation, that their dev broke half the planets web projects when he broke them intentionally.
And this is why I had so much trouble learning JavaScript. It was unclear where the language ended and the libraries & frameworks began.
The strategy I use for JS is to try to find things on MDN first, since a lot of the time there's the JS method, and then there's the jQuery/whatever-framework method, and MDN only has the prior.
I remember reading about this years ago, even affected internal Facebook dev team when it happened.
The dev was (rightfully) angry at NPM about another project and asked NPM to delist all of them. For some reason NPM at the time allowed this. I think they just had never thought about the problems it could cause before. Deployments to package managers, especially open source deployments with irrevocable licences, shouldn't be allowed to be removed. Doubly so once they're depended on. NPM's policy changed and is now more in line with that.
It affected pretty much everyone because some very popular frameworks at the time pulled left pad in transitively through other modules. Then because those popular frameworks did and most everyone was using those frameworks it broke pretty much everyone.
Step one: Create random package that does something trivial that’s done often.
Step two: Start making PR’s to lots of open source projects replacing a number of lines of code with your new package.
Step three: Work hard to get your package into another package that’s used by many.
Step four: Update your CV to reflect that you build software that thousands of companies depend upon.
Step five: Profit from the stupid incentives created by companies hiring people that pad their CV’s by making redundant software and push them into everything they can to make sure everyday is dependency hell.
Gotta make a name somehow. (/s)
Packages often have recursive dependencies. There are some conscious packages that go the extra mile to not have any dependencies, but it’s very rare in the JavaScript ecosystem. Welcome to hell. You can at least use dev dependencies to avoid downloading them in CI etc., but that’s about it.
Welcome to JavaScript! This is the expected behavior. For the life of me, it still boggles my mind. I refuse to write JavaScript anymore.
There should be a way to specify it as a "dev dependency" so it is not part of your project, only local.
In my mind, it's arisen as a result of two things about the JS ecosystem:
A) JS doesn't have a standard BCL, like most languages. It has the DOM API, for interacting with the browser, but it has almost no functionality baked in that is just there for the sake of it. There's a few exceptions in more recent years, like Map and Set, but most menial tasks still involve rolling your own implementation, or pulling in a 3rd party one.
B) Almost everyone places delivery size as the most-important concern in web apps, so that actively encourages (or at least, it used to, less so now that tree shaking is a big thing) developers to package things up at the tiniest possible granularity, in order to prevent applications being built with a ton of code that isn't being used. Ironically, at scale, this effort had the exact opposite of the desired effect.
Yeah, that seems bonkers, but it's how npm works. I don't always code in JS, but if I do: a) its code that's going to run in a browser and b) I never ever use any JS dependencies aside from browser builtins. It's about the only way to opt out of the dependency nightmare that is "modern web dev".
Ok, I lied a little bit. In my job, I sometimes do JS work on projects with Grunt, Bower, Backbone, jQuery and a gorillion other dependencies. But when I have full autonomy over a codebase like with my side projects, my style is as above.
To qualify that even more, even in my side projects, I often use minifiers, but not ones written in JS or pulled in via NPM.
Of course, that probably doesn't help much when you have need of functionality that would be much less trivial to make yourself. Again at my job, we use JsBarcode to generate images of barcodes. That would be a royal pain to implement from scratch. If I needed that functionality in a side project, I'd probably just bite the bullet and pull it in from Bower with 30 other bulky dependencies. (Or more likely just refrain from taking on that particular side project. Or possibly generate barcodes server-side.)
Heck yeah, Backbone! Did you know there’s a new maintainer on the project? He’s been busy lately trying to clean up the codebase.
I also use Semantic UI(‘s community fork, Fomantic UI) so I can avoid the hell that is modern UI frameworks. It works really well with Backbone
If I'm coding for myself, jQuery definitely. The one piece of JS code I made for sharing? Vanilla JS.
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.