3 ms·

> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1],

> You'll find much harsher critics of Node/NPM in these parts! They're ill-informed. GPP is correct that, for example pip is fundamentally inferior to npm [1], and those that insist on throwing shade at npm on HN should be corrected. They're wrong, and insulting a sound, well maintained project, without basis. [1] https://github.com/pypa/pip/issues/988 https://github.com/pypa/pip/issues/988

kbenson 8y ago
> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem. Client issues are generally easily resolved, just use a different client. For npm, this could be yarn. For cpan, this could be cpanm, or cpanplus, etc. If it's indeed the repository we are talking about, there are some obvious things that could be done to greatly improve it the NPM module ecosystem. For example, how about automating module tests against different versions of Node to determine whether it's in a good running status now for the current and prior interpreter versions, on the platforms it can be run on? [1] How about a prior version, in case you're trying to figure out if the version you're on has a known problem on the platform combo you're running on? [2] Or perhaps you want to know what the documentation and module structure looked like for a module a long time ago, like20 published versions and over a decade ago, because sometimes you run across old code? [3] Or as an author, the ability to upload a version, even for testing, and getting an automated report a couple days later about how well it runs on that entire version/architecture matrix with any problems you might want to look into? In case you didn't notice the trend, I'm talking about CPAN here, which has been in existence for over two decades, and many of the features I've noted have been around for at least half that time. All in and for a language that most JS devs probably think isn't in use anymore, and on encountering a professional Perl developer would probably think they just encountered a unicorn or dinosaur. Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. Given the current popularity of JS and the massive corporate interest and sponsership, I frankly find the current situation somewhat disgusting. The only thing keeping JS from having an amazing module ecosystem is ambition. Sure, NPM might be a sound, well maintained project (points I think are debatable), but it could be so much more, and that's what we should be talking about, not almost annual fuckups[4] they seem content with dealing with. 1: http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 2: http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 3: https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/lib/DBIx/Class.pm https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/... 4: https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=false&dateRange=all&type=story https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=f...
- allover 8y ago
  > Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted. > I frankly find the current situation somewhat disgusting. This feels so hyperbolic though. The things you mention are cool 'nice-to-haves', to say not having them is 'disgusting' is a huge stretch in my opinion.
  - kbenson 8y ago
    > This feels so hyperbolic though. The things you mention are cool 'nice-to-haves' What I find somewhat disgusting is the massive amount of mistakes they've made over the years, and the time they've had to take to fix them, that could have been mitigated or entirely avoided by surveying best practices from other package management systems that have gone through the same pains. 2018-05-28 - ERR! 418 I'm a teapot (this is not a joke) https://github.com/npm/npm/issues/20791 https://news.ycombinator.com/item?id=17175960 2018-02-21 - Critical Linux filesystem permissions are being changed by latest version https://github.com/npm/npm/issues/19883 https://news.ycombinator.com/item?id=16435305 2017-08-01 - Typosquatting package names https://twitter.com/o_cee/status/892306836199800836 https://news.ycombinator.com/item?id=14905675 (a little obtuse, but moderated package namespaces with trusted maintainers can mitigate this, and spread load from levenshtein distance checks.) 2017-11-03 - Visual Studio Code 1.7 overloaded npmjs.org, release reverted https://news.ycombinator.com/item?id=12860806 (10% increase in NPM load, specifically to 404 pages, causes NPM to fall over due to naive 404 handling and apparently, poor ability to scale. Good thing they caught it at 10% instead of the 200% it would have reached...). 2016-03-29 - changes to npm’s unpublish policy https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy https://news.ycombinator.com/item?id=11382885 2014-02-28 - npm’s Self-Signed Certificate is No More https://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-no-more https://news.ycombinator.com/item?id=7320833 2012-03-08 - npm (Node's package manager) leaks all user password hashes and salts https://gist.github.com/jashkenas/2001456 https://news.ycombinator.com/item?id=3679996 That's just from the first page of the HN search I included previously (link 4), I doubt it's really exhaustive. Now, to me, that list of problems would be bad enough, but NPM is actually run by a for-profit company, and gates certain features behind paid accounts. So what we have is a business, catering to what is likely the largest current group of developers that exist, for a language with corporate backing by multiple very large companies, providing vital infrastructure support for that language and those users, and getting their asses handed to them in comparison to some others who are manned by people volunteering spare time, skill and equipment. I mean, I would cut them a little slack if they seemed to have plans for making stuff better and a roadmap and it was just a matter of time, effort and resources they were lacking, but it seems to continuously be a case of them waiting until the shit hits the fan and they're forced to first take a look and see how to fix this new problem they've never envisioned, and then figure out their solution. Sure, it can sound hyperbolic initially, but I think that's just because people haven't really stopped to take stock of what's really going on here, and how it's not really getting better in any useful way. In the midst of emergency fixes is not how you should plan your new features. :/

kbenson 8y ago

> those that insist on throwing shade at npm on HN should be corrected. Preferrably by giving them better ammunition, since I do see NPM as substandard in quite a few ways, which is inexcusable when there do exist examples to learn from (whether it be a positive or negative influence). First, it helps to clarify whether we are talking about npm the client or NPM the repository and ecosystem. Client issues are generally easily resolved, just use a different client. For npm, this could be yarn. For cpan, this could be cpanm, or cpanplus, etc. If it's indeed the repository we are talking about, there are some obvious things that could be done to greatly improve it the NPM module ecosystem. For example, how about automating module tests against different versions of Node to determine whether it's in a good running status now for the current and prior interpreter versions, on the platforms it can be run on? [1] How about a prior version, in case you're trying to figure out if the version you're on has a known problem on the platform combo you're running on? [2] Or perhaps you want to know what the documentation and module structure looked like for a module a long time ago, like20 published versions and over a decade ago, because sometimes you run across old code? [3] Or as an author, the ability to upload a version, even for testing, and getting an automated report a couple days later about how well it runs on that entire version/architecture matrix with any problems you might want to look into? In case you didn't notice the trend, I'm talking about CPAN here, which has been in existence for over two decades, and many of the features I've noted have been around for at least half that time. All in and for a language that most JS devs probably think isn't in use anymore, and on encountering a professional Perl developer would probably think they just encountered a unicorn or dinosaur. Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. Given the current popularity of JS and the massive corporate interest and sponsership, I frankly find the current situation somewhat disgusting. The only thing keeping JS from having an amazing module ecosystem is ambition. Sure, NPM might be a sound, well maintained project (points I think are debatable), but it could be so much more, and that's what we should be talking about, not almost annual fuckups[4] they seem content with dealing with. 1: http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 http://matrix.cpantesters.org/?dist=DBIx-Class+0.082841 2: http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 http://matrix.cpantesters.org/?dist=DBIx-Class+0.08271 3: https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/lib/DBIx/Class.pm https://metacpan.org/pod/release/MSTROUT/DBIx-Class-0.08000/... 4: https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=false&dateRange=all&type=story https://hn.algolia.com/?query=npm&sort=byPopularity&prefix=f...

allover 8y ago
> Sure, NPM isn't all that bad compared to some of the examples that were put forth, but the problem is that those examples are a limited subset of what exists. That was all I was responding to. I definitely learned some cool stuff from your comment, and appreciate that, but my point was simply that the all the drive-by FUD that npm gets on HN is unwarranted. > I frankly find the current situation somewhat disgusting. This feels so hyperbolic though. The things you mention are cool 'nice-to-haves', to say not having them is 'disgusting' is a huge stretch in my opinion.
- kbenson 8y ago
  > This feels so hyperbolic though. The things you mention are cool 'nice-to-haves' What I find somewhat disgusting is the massive amount of mistakes they've made over the years, and the time they've had to take to fix them, that could have been mitigated or entirely avoided by surveying best practices from other package management systems that have gone through the same pains. 2018-05-28 - ERR! 418 I'm a teapot (this is not a joke) https://github.com/npm/npm/issues/20791 https://news.ycombinator.com/item?id=17175960 2018-02-21 - Critical Linux filesystem permissions are being changed by latest version https://github.com/npm/npm/issues/19883 https://news.ycombinator.com/item?id=16435305 2017-08-01 - Typosquatting package names https://twitter.com/o_cee/status/892306836199800836 https://news.ycombinator.com/item?id=14905675 (a little obtuse, but moderated package namespaces with trusted maintainers can mitigate this, and spread load from levenshtein distance checks.) 2017-11-03 - Visual Studio Code 1.7 overloaded npmjs.org, release reverted https://news.ycombinator.com/item?id=12860806 (10% increase in NPM load, specifically to 404 pages, causes NPM to fall over due to naive 404 handling and apparently, poor ability to scale. Good thing they caught it at 10% instead of the 200% it would have reached...). 2016-03-29 - changes to npm’s unpublish policy https://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy https://news.ycombinator.com/item?id=11382885 2014-02-28 - npm’s Self-Signed Certificate is No More https://blog.npmjs.org/post/78085451721/npms-self-signed-certificate-is-no-more https://news.ycombinator.com/item?id=7320833 2012-03-08 - npm (Node's package manager) leaks all user password hashes and salts https://gist.github.com/jashkenas/2001456 https://news.ycombinator.com/item?id=3679996 That's just from the first page of the HN search I included previously (link 4), I doubt it's really exhaustive. Now, to me, that list of problems would be bad enough, but NPM is actually run by a for-profit company, and gates certain features behind paid accounts. So what we have is a business, catering to what is likely the largest current group of developers that exist, for a language with corporate backing by multiple very large companies, providing vital infrastructure support for that language and those users, and getting their asses handed to them in comparison to some others who are manned by people volunteering spare time, skill and equipment. I mean, I would cut them a little slack if they seemed to have plans for making stuff better and a roadmap and it was just a matter of time, effort and resources they were lacking, but it seems to continuously be a case of them waiting until the shit hits the fan and they're forced to first take a look and see how to fix this new problem they've never envisioned, and then figure out their solution. Sure, it can sound hyperbolic initially, but I think that's just because people haven't really stopped to take stock of what's really going on here, and how it's not really getting better in any useful way. In the midst of emergency fixes is not how you should plan your new features. :/