5 ms·

Dawn of the Dead NPM Packages

78 points by rnosov 9y ago

royjacobs 9y ago
It's a shame that npm seems to have such a hard time doing what's it's supposed to do: making packages easy to discover, use and keep using.
CaliforniaKarl 9y ago
I’m guessing that the problem is the search engine? It would be interesting to compare the search/suggestion engines of CPAN/PyPI/rubygems/npm/CRAN, because this can’t be a problem that has only been faced by npm.
- tyingq 9y ago
  Part of it is scale and growth rate. CPAN has around 36k packages but it's been around decades. NPM exceeded 350k a while ago. See http://www.modulecounts.com http://www.modulecounts.com
  - TAForObvReasons 9y ago
    NPM used to have its own search, then one day in late 2016 decided to outsource it to https://npms.io/ https://npms.io/ . That may be directly related to the issue at hand
    - SenHeng 9y ago
      Using the search terms used in TFA, npms.io seems to return the expected results compared to whatever's used on npmjs.com. So I don't think we should blame them.
z3t4 9y ago
most of the code we run every day is very old. the idea with open source packages is that you do not have to repeat the work made by others. but you can improve it if you can/want. old code is often "battle tested" and thus it can actually be safer then something that get constant updates.
- yjftsjthsd-h 9y ago
  Old can be good, and unmaintained isn't always fatal, but many npm packages are network-facing, where security vulnerabilities need to be addressed.
- shp0ngle 9y ago
  This is about packages that are just inactive forks of more popular packages Sure, you might want to install them, but probably you don't
- btbuildem 9y ago
  I don't think that holds in the JS world, practically or philosophically speaking.
- cyphar 9y ago
  That's not related to the issue at hand, which is that users searching for actively maintained projects are getting sent to old unmaintained projects that are abandoned for reasons other than "it is so stable it needs no updates". It's like trying to install CUPS (last updated a month ago) but being redirected to cup-stacker-pro (last updated in 1997). Sure, it's definitely old code, but is it really a good idea to install it? But I also disagree that old code is "battle tested". Old codebases and old projects are a different story. Running a binary built 10 years ago isn't generally a good idea, but running a modern release of a 10-year-old project is almost always better than a project started 2 weeks ago. The benefit of old codebases is the experience of the maintainers involved, but you don't get that benefit if the codebase hasn't been maintained (or you're using a release that was made before they gained that experience).
RyJones 9y ago
I’ve had a lot of difficulty dealing with NPM as a customer. Changing a billing date is not possible, and you cannot get annual plans that are reasonably priced. As it is, I expense $14 a month in NPM expenses every month with no ability to switch to an annual billing. The request to change a billing date was met with a hilarious response. Pause using the paid plan until you get to the day where you want billing to start, then unpause. In the interim, access to the paid features would be gone. Thanks, but no! GitHub, by way of comparison, was a dream. Change the billing date to the first? Done and done.
treve 9y ago
I also noticed the search is pretty awful. I published a library that was impossible to find (even if written in full) because hitting 'enter' after a search just went to a more popular library that must have a closely matching term somewhere in their keywords or description. So my only option for making the library findable at all, was to use a word that was unlikely to appear in any other fields of other packages. I settled on a dutch translation of one of the concepts used in the package, that would still have a predictable spelling if an English speaker heard it. It's unfortunate, because the implication is that if you want your package to be found at all (assuming you already know the full name of the package, not even talking about discoverability), you need to pick a name that's unlikely to have any bearing on the function of the package.
franciscop 9y ago
I am a dev who uses Node.js a lot and published quite a few packages; the state of npm is very, very sad. It has evolved from being one of the great things on Node.js to something you have to fight constantly with counterintuitive defaults everywhere. Not that it used to be much better, but these issues were only acceptable when the ecosystem was smaller.
tlrobinson 9y ago
FWIW I usually use https://npmcompare.com/ https://npmcompare.com/ to find packages that are actively maintained
- franciscop 9y ago
  Doesn't work on mobile
  - tlrobinson 9y ago
    Fortunately I (and probably most people) don’t usually program on their mobile devices...
    - franciscop 9y ago
      Ah didn't think that one, just wanted to quickly test it. But I do use my phone on dead times (like train) and some times check npm there to see if my idea exists and for possible names. Guess not such a big case for USA where you mostly drive everywhere though.
    - ec109685 9y ago
      The pop-over ad is pretty awful too.
shp0ngle 9y ago
Ahhh, the wonderful world of npm, where every small task has 20 libraries that are all named the same and half of them are abandoned and the other half have confusingly overlapping feature sets, and sometimes are actually all from the same authors.
- sumoboy 9y ago
  I thought wordpress plugins were bad keeping up to date, NPM is the same nightmare. Better filtering needed.
dguo 9y ago
Last year, I switched to using the Yarn website[1] to search for packages. It's powered by Algolia[2], and it delivers much better results in my experience. [1]: https://yarnpkg.com https://yarnpkg.com [2]: https://discourse.algolia.com/t/2016-algolia-community-gift-yarn-package-search/319 https://discourse.algolia.com/t/2016-algolia-community-gift-...
deathtrader666 9y ago
The Elm package library is such a breath of fresh air! I'm glad I moved over.
sbr464 9y ago
I agree with the author 100%. I personally never use npm directly for search. I also prefer to just use google as a start, and usually find the github results there more appealing. I realize it’s not npm’s prerogative to satisfy what I like, but I don’t really understand their motivations either. A basic account costs $5-15/month for what I feel is a critical ecosystem service as the author puts it. It feels like the quality of the UI is related to this cheaper price, when I for one would pay much more for a better experience. It feels like they are selling themselves short for the importance they have achieved. It kind of feels like either the original product managers lost motivation, or they’ve become too big to have people that really care. (Or have to say this, they are just stuck up hardcore devs that don’t care about the real world) I’m definitely not ranting and appreciate npm, but wanted to write my feedback here in case it’s read by them.
tomc1985 9y ago
This is a really harsh assessment of a crappy search engine.
- sbr464 9y ago
  I honestly wouldn’t refer to them as a search (engine). Implementing a keyword search with a Lodash function and a few if/else rules feels like it would provide better or comparable results to the current offering. I wouldn’t refer to that as an engine.
iamleppert 9y ago
It’s really sad that npm has a great platform and amazing opportunity to innovate and deliver a great developer UX. I was going to apply there and see if I could get an interview to figure out what’s up with them, and maybe to try and take things in a better direction.

78 points by rnosov 9y ago

It's a shame that npm seems to have such a hard time doing what's it's supposed to do: making packages easy to discover, use and keep using.

CaliforniaKarl 9y ago

I’m guessing that the problem is the search engine? It would be interesting to compare the search/suggestion engines of CPAN/PyPI/rubygems/npm/CRAN, because this can’t be a problem that has only been faced by npm.

tyingq 9y ago
Part of it is scale and growth rate. CPAN has around 36k packages but it's been around decades. NPM exceeded 350k a while ago. See http://www.modulecounts.com http://www.modulecounts.com
- TAForObvReasons 9y ago
  NPM used to have its own search, then one day in late 2016 decided to outsource it to https://npms.io/ https://npms.io/ . That may be directly related to the issue at hand
  - SenHeng 9y ago
    Using the search terms used in TFA, npms.io seems to return the expected results compared to whatever's used on npmjs.com. So I don't think we should blame them.

z3t4 9y ago

most of the code we run every day is very old. the idea with open source packages is that you do not have to repeat the work made by others. but you can improve it if you can/want. old code is often "battle tested" and thus it can actually be safer then something that get constant updates.

yjftsjthsd-h 9y ago
Old can be good, and unmaintained isn't always fatal, but many npm packages are network-facing, where security vulnerabilities need to be addressed.
shp0ngle 9y ago
This is about packages that are just inactive forks of more popular packages Sure, you might want to install them, but probably you don't
btbuildem 9y ago
I don't think that holds in the JS world, practically or philosophically speaking.
cyphar 9y ago
That's not related to the issue at hand, which is that users searching for actively maintained projects are getting sent to old unmaintained projects that are abandoned for reasons other than "it is so stable it needs no updates". It's like trying to install CUPS (last updated a month ago) but being redirected to cup-stacker-pro (last updated in 1997). Sure, it's definitely old code, but is it really a good idea to install it? But I also disagree that old code is "battle tested". Old codebases and old projects are a different story. Running a binary built 10 years ago isn't generally a good idea, but running a modern release of a 10-year-old project is almost always better than a project started 2 weeks ago. The benefit of old codebases is the experience of the maintainers involved, but you don't get that benefit if the codebase hasn't been maintained (or you're using a release that was made before they gained that experience).

RyJones 9y ago

I’ve had a lot of difficulty dealing with NPM as a customer. Changing a billing date is not possible, and you cannot get annual plans that are reasonably priced. As it is, I expense $14 a month in NPM expenses every month with no ability to switch to an annual billing. The request to change a billing date was met with a hilarious response. Pause using the paid plan until you get to the day where you want billing to start, then unpause. In the interim, access to the paid features would be gone. Thanks, but no! GitHub, by way of comparison, was a dream. Change the billing date to the first? Done and done.

treve 9y ago

I also noticed the search is pretty awful. I published a library that was impossible to find (even if written in full) because hitting 'enter' after a search just went to a more popular library that must have a closely matching term somewhere in their keywords or description. So my only option for making the library findable at all, was to use a word that was unlikely to appear in any other fields of other packages. I settled on a dutch translation of one of the concepts used in the package, that would still have a predictable spelling if an English speaker heard it. It's unfortunate, because the implication is that if you want your package to be found at all (assuming you already know the full name of the package, not even talking about discoverability), you need to pick a name that's unlikely to have any bearing on the function of the package.

franciscop 9y ago

I am a dev who uses Node.js a lot and published quite a few packages; the state of npm is very, very sad. It has evolved from being one of the great things on Node.js to something you have to fight constantly with counterintuitive defaults everywhere. Not that it used to be much better, but these issues were only acceptable when the ecosystem was smaller.

tlrobinson 9y ago

FWIW I usually use https://npmcompare.com/ https://npmcompare.com/ to find packages that are actively maintained

franciscop 9y ago
Doesn't work on mobile
- tlrobinson 9y ago
  Fortunately I (and probably most people) don’t usually program on their mobile devices...
  - franciscop 9y ago
    Ah didn't think that one, just wanted to quickly test it. But I do use my phone on dead times (like train) and some times check npm there to see if my idea exists and for possible names. Guess not such a big case for USA where you mostly drive everywhere though.
  - ec109685 9y ago
    The pop-over ad is pretty awful too.

shp0ngle 9y ago

Ahhh, the wonderful world of npm, where every small task has 20 libraries that are all named the same and half of them are abandoned and the other half have confusingly overlapping feature sets, and sometimes are actually all from the same authors.

sumoboy 9y ago
I thought wordpress plugins were bad keeping up to date, NPM is the same nightmare. Better filtering needed.

dguo 9y ago

Last year, I switched to using the Yarn website[1] to search for packages. It's powered by Algolia[2], and it delivers much better results in my experience. [1]: https://yarnpkg.com https://yarnpkg.com [2]: https://discourse.algolia.com/t/2016-algolia-community-gift-yarn-package-search/319 https://discourse.algolia.com/t/2016-algolia-community-gift-...

deathtrader666 9y ago

The Elm package library is such a breath of fresh air! I'm glad I moved over.

sbr464 9y ago

I agree with the author 100%. I personally never use npm directly for search. I also prefer to just use google as a start, and usually find the github results there more appealing. I realize it’s not npm’s prerogative to satisfy what I like, but I don’t really understand their motivations either. A basic account costs $5-15/month for what I feel is a critical ecosystem service as the author puts it. It feels like the quality of the UI is related to this cheaper price, when I for one would pay much more for a better experience. It feels like they are selling themselves short for the importance they have achieved. It kind of feels like either the original product managers lost motivation, or they’ve become too big to have people that really care. (Or have to say this, they are just stuck up hardcore devs that don’t care about the real world) I’m definitely not ranting and appreciate npm, but wanted to write my feedback here in case it’s read by them.

tomc1985 9y ago

This is a really harsh assessment of a crappy search engine.

sbr464 9y ago
I honestly wouldn’t refer to them as a search (engine). Implementing a keyword search with a Lodash function and a few if/else rules feels like it would provide better or comparable results to the current offering. I wouldn’t refer to that as an engine.

iamleppert 9y ago

It’s really sad that npm has a great platform and amazing opportunity to innovate and deliver a great developer UX. I was going to apply there and see if I could get an interview to figure out what’s up with them, and maybe to try and take things in a better direction.