4 ms·

Or even just a house or bridge. Completely trivial-seeming things are just very complex.

krapp 3y ago
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.
- jdthedisciple 3y ago
  > 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. LOL, perfect summary of the SOTA npm ecosystem.
  - moon_moon 3y ago
    [dead]
- ironmagma 3y ago
  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.
  - krapp 3y ago
    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.
    - ironmagma 3y ago
      > you won't find any C code that takes the Unix philosophy to such an extreme Challenge accepted: https://github.com/coreutils/coreutils/blob/master/src/true.c https://github.com/coreutils/coreutils/blob/master/src/true.... [1] > one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly Yes, easily. The same argument can be extended, and even by the same virtue, to Bash programs and the Unix stack. [1] See also: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
      - krapp 3y ago
        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?
        ironmagma 3y ago
        > You can't compare Javascript to C or Bash 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.

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.

jdthedisciple 3y ago
> 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. LOL, perfect summary of the SOTA npm ecosystem.
- moon_moon 3y ago
  [dead]
ironmagma 3y ago
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.
- krapp 3y ago
  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.
  - ironmagma 3y ago
    > you won't find any C code that takes the Unix philosophy to such an extreme Challenge accepted: https://github.com/coreutils/coreutils/blob/master/src/true.c https://github.com/coreutils/coreutils/blob/master/src/true.... [1] > one could easily argue the excessive granularity of packages in JS causes it to do a lot of things badly Yes, easily. The same argument can be extended, and even by the same virtue, to Bash programs and the Unix stack. [1] See also: http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html http://trillian.mit.edu/~jc/humor/ATT_Copyright_true.html
    - krapp 3y ago
      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?
      - ironmagma 3y ago
        > You can't compare Javascript to C or Bash 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.