5 ms·

JavaScript Developers: The New Kings of Software

7 points by lolptdr 11y ago

bootload 11y ago
"npm is the bigger than any other package manager of any language." that isn't necessarily good, cf: "Kill Your Dependencies" https://news.ycombinator.com/item?id=11065769 https://news.ycombinator.com/item?id=11065769
- stephenr 11y ago
  how many of those npm packages exist because a js developer didn't want to use/know about an existing shell command so s/he created a node shell script? And how many are tiny little packages that provide a single piece of functionality that other languages either include in the standard library or bundle up with related functions? I laugh and cry every time someone says npm is a good package manager. I recently had to help a client debug why their angular(I think?) front end wasn't working in safari or Firefox. Turns out they were (via various packages) requiring 9 different copies of a package that just handles parsing query strings, and at v6.0 it went to let/const syntax and broke browsers. That package was created 18 months ago (July 2014) and is already at 6.x. I don't do js dev these days but if I did, npm would be the last resort for me.
  - btdiehr 11y ago
    Could you clarify which parts of your anecdote can be attributed to `npm` in a way that's at all unique to `npm`? This story sounds like it amounts to "I saw a bad piece of software" and "People put modules I don't like on NPM".
    - stephenr 11y ago
      It amounts to "npm is a pig of a dependency manager and the statistics about how many packages it has are not realistic because JavaScript developers a) insist on recreating every single tool as a node script; and b) distribute the tiniest pieces of functionality via seperate packages where more sane packaging systems/communities tend to group things together logically.
      - btdiehr 11y ago
        Is it not a testament to how easy NPM has made it, that it is flooded with beginners? Is that not the fate of any sufficiently popular package manager? Your disdain seems to be more about how much you dislike the javascript community than how much you dislike the tool that is NPM.
        atomi 11y ago
        Making it easy to publish should not be a main objective for a package manager. Things like maintainability and security are more important.
        stephenr 11y ago
        "Easy" should not be the primary goal of a package manager. Someone releasing (I say releasing and not maintaining, because I'm certain a good number of the npm packages available are effectively unmaintained) a package should be sufficiently aware of both the language and the package manager itself to understand how they work. In my earlier tale I mentioned a package that was included 9 times. I tried to dig into finding why the various dependencies have such old versions, but I gave up in sake of my own sanity when I discovered this scenario: The project requires 47 packages at the top level, 33 of which have exact version match requirements. One of the dependencies is `grunt-contrib-watch` with an exact version requirement of 0.6.1. That package has a dependency on `tiny-lr-fork` with yet another exact version requirement of 0.0.5. But it gets worse, because `tiny-lr-fork` (as the name suggests) is a fork of an older package called `tiny-lr` which was unmaintained for a while. But now, `tiny-lr` is more up-to-date than the fork is (and more confusingly, the `fork` npmjs page points to the upstream github repo, NOT the fork repo). And that is where we find our dependency on `qs` with a "approximate" (as npm calls it) version requirement of ~0.5.2 I actually dug a little further with a one-liner I found to identify (and count) the duplicated dependencies from the tree: 120 unique packages, the highest dupe count is 24. TWENTY FOUR copies of the same module, again ranging from 0.X releases to 3.x. The node_modules directory is 200MB. The entire back-end application that actually makes the fucking thing work, is 1.1MB. Are you FUCKING KIDDING ME!?

7 points by lolptdr 11y ago

"npm is the bigger than any other package manager of any language." that isn't necessarily good, cf: "Kill Your Dependencies" https://news.ycombinator.com/item?id=11065769 https://news.ycombinator.com/item?id=11065769

stephenr 11y ago
how many of those npm packages exist because a js developer didn't want to use/know about an existing shell command so s/he created a node shell script? And how many are tiny little packages that provide a single piece of functionality that other languages either include in the standard library or bundle up with related functions? I laugh and cry every time someone says npm is a good package manager. I recently had to help a client debug why their angular(I think?) front end wasn't working in safari or Firefox. Turns out they were (via various packages) requiring 9 different copies of a package that just handles parsing query strings, and at v6.0 it went to let/const syntax and broke browsers. That package was created 18 months ago (July 2014) and is already at 6.x. I don't do js dev these days but if I did, npm would be the last resort for me.
- btdiehr 11y ago
  Could you clarify which parts of your anecdote can be attributed to `npm` in a way that's at all unique to `npm`? This story sounds like it amounts to "I saw a bad piece of software" and "People put modules I don't like on NPM".
  - stephenr 11y ago
    It amounts to "npm is a pig of a dependency manager and the statistics about how many packages it has are not realistic because JavaScript developers a) insist on recreating every single tool as a node script; and b) distribute the tiniest pieces of functionality via seperate packages where more sane packaging systems/communities tend to group things together logically.
    - btdiehr 11y ago
      Is it not a testament to how easy NPM has made it, that it is flooded with beginners? Is that not the fate of any sufficiently popular package manager? Your disdain seems to be more about how much you dislike the javascript community than how much you dislike the tool that is NPM.
      - atomi 11y ago
        Making it easy to publish should not be a main objective for a package manager. Things like maintainability and security are more important.
      - stephenr 11y ago
        "Easy" should not be the primary goal of a package manager. Someone releasing (I say releasing and not maintaining, because I'm certain a good number of the npm packages available are effectively unmaintained) a package should be sufficiently aware of both the language and the package manager itself to understand how they work. In my earlier tale I mentioned a package that was included 9 times. I tried to dig into finding why the various dependencies have such old versions, but I gave up in sake of my own sanity when I discovered this scenario: The project requires 47 packages at the top level, 33 of which have exact version match requirements. One of the dependencies is `grunt-contrib-watch` with an exact version requirement of 0.6.1. That package has a dependency on `tiny-lr-fork` with yet another exact version requirement of 0.0.5. But it gets worse, because `tiny-lr-fork` (as the name suggests) is a fork of an older package called `tiny-lr` which was unmaintained for a while. But now, `tiny-lr` is more up-to-date than the fork is (and more confusingly, the `fork` npmjs page points to the upstream github repo, NOT the fork repo). And that is where we find our dependency on `qs` with a "approximate" (as npm calls it) version requirement of ~0.5.2 I actually dug a little further with a one-liner I found to identify (and count) the duplicated dependencies from the tree: 120 unique packages, the highest dupe count is 24. TWENTY FOUR copies of the same module, again ranging from 0.X releases to 3.x. The node_modules directory is 200MB. The entire back-end application that actually makes the fucking thing work, is 1.1MB. Are you FUCKING KIDDING ME!?