The javascript ecosystem is unnecessarily complex. What would be a single library in any other language (including javascript, prior to NPM) is hundreds of separate single-line modules in JS, each likely with its own bespoke testing framework and toolchain. You have a package to test if a number is even that depends on a package to test if a number is odd that depends on a package to test if a number is an integer that depends on a package to test if a number is a number. And there's probably a whole-ass C compiler in there somewhere because why not?
Whereas any other developer in any other language will just use a modulus and call it a day.
Comparing that to the complexity inherent to an internal combustion engine or a house or a bridge is an insult to engineering.
> You have a package to test if a number is even that depends on a package to test if a number is odd that depends on a package to test if a number is an integer that depends on a package to test if a number is a number.
That makes for a great caricature, but React does not depend on `is-even`. As for the small modules, this is just the Unix philosophy lived out, "do one thing well," which is ironically what a lot of hardcore systems people used to preach.
Doing one thing well doesn't require doing only one thing per library, you won't find any C code that takes the Unix philosophy to such an extreme. And one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly.
Bash is barely even a language. No one (sane) is writing an entire application in it. And no one (sane) is writing an OS kernel in Javascript. The context in which a language is run and the kinds of programs written with it matter. You can't compare Javascript to C or Bash or anything running close to the metal, a better comparison would be to Python or Lua - other high level dynamic languages.
There is no technical reason why Javascript packages need to be as small as they are. The strongest argument for it would be that smaller packages travel faster over the wire, and save bandwidth, but that doesn't apply when hundreds or thousands of dependencies are involved. Which is why everyone just uses webpack. And yet the web is still bloated to the point of morbidity. So what even is the point?
I'll remind you that you are the one who mentioned C. I just mentioned the Unix philosophy, which really should be language-agnostic.
> So what even is the point?
There actually is a reason, which is bundle size. There is no standard library in JavaScript, or at least any standard library present may not match the version you expect, due to different browser versions. The target platform also has no pre-downloaded dynamically linkable libraries, so everything must be bundled statically. If many of your dependencies can use some common logic, that reduces the bundle size. The fact that they aren't is too bad, but reflects mismanagement more than nature of the system, since the system enables sharing.
But regardless, what's the point of having small dependencies at all? I think there is a pretty strong reason to do that and it's to make the dependencies easy to think about, their scope limited, the chances for bugs small. In Python, it is quite trivial to end up with two incompatible dependencies, since you cannot reconcile versions easily. Recently this has gotten better with Poetry, but NPM has had a long head start on it in this aspect.
There's JS tooling for bundling so the code over the wire will only include the files and modules referenced.
Much like a function in a C source for doesn't output two files, the bundled and monitored output is only one file much of the time. The browser doesn't download 1400 separate files or even all the code in those dependencies.
For React in particular there are development and production versions of the library.
Not that bundles can't or don't get huge. Not that they aren't often excessive. Only in that they aren't nearly as bad at first glance.
