It has one dependancy.
No, there are 2 reasons for this dependency creep:
- the fact JS has a so few features and such a little stdlib. So everyone has to rewrite even basic stuff.
- the community culture toward stability, maintenance and future proofing is almost inexistent in JS.
Too many JS devs have only ever coded in JS. This give them have a very twisted, unbalanced view of programming.
"very new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly, under duress, because you completely exhausted all your other options. Code is only our enemy because there are so many of us programmers writing so damn much of it. If you can't get away with no code, the next best thing is to start with brevity."
More code, more bugs, more issues. 388 packages is ridiculous compared to practically every major system including operating systems. Javascript is Stockholm syndrome.
No. Using a package for a single function doesn't preclude code reuse.
Look at underscore.get package. You could write your own recursive key finder (which I have before), and so could every package author, and you'd have 10x the amount of implementations of a recursive key finder.
A single require of underscore.get by you and other authors means you have a single, well tested implementation with a million other users rather than 10 low quality ones.
const {get} = require("underscore.get");
get(obj, 'a[0].b', defaultValue);
Exactly. If it's a difficult line of code, with edge cases, requiring unit tests, etc. then sure. Algorithms are a great example of this.
Using your own example: how many badly written copies of https://github.com/NarHakobyan/underscore.get/blob/master/un... do you want?
Look at what Phoenix (https://hexdocs.pm/phoenix/overview.html) and Brunch (https://brunch.io/) can do. To suggest 388 packages for all that stuff is too much is ridiculous - there's a lot of functionality, so there's a lot of code. The fact that it's not one huge, opaque blob is a good thing. Could they be implemented with less code? Maybe. Does that mean they'd be better for it? I don't think I've ever come across a reasonable argument that says 'less code is always better'.
You could very reasonably argue that you don't need all those features, and maybe the two things are bloated. I would suggest that means you've picked two things that do way more than you need, and you've not chosen your tech stack very well.