6 ms·

I don't believe yet another package manager is going to fix anything, more likely it'll take years to reach maturity, will be riddled with bugs until then, and

by jammi 7y ago

I don't believe yet another package manager is going to fix anything, more likely it'll take years to reach maturity, will be riddled with bugs until then, and have some serious fundamental issues on its own that will be revealed down the path, if it ever gains popularity. Don't fix it if it aint broke should be a motto for more developers. Settling for good enough prevents second system effects and retards immaturity in the form new "trendy" products that over-promise and under-deliver solutions. Nothing is perfect, but replacing something from scratch because of some mostly irrelevant issues that would be better handled by improving the standard solution usually just causes more issues than it solves.

skrebbel 7y ago
> mostly irrelevant issues 95% of the talk is about why those issues aren't irrelevant. Care to respond to those?
- gridlockd 7y ago
  I think 100% of these issues are irrelevant in practice, 99.9% of the time. Sure, there was that "left-pad" thing one time. Sometimes NPM is down briefly. Otherwise, it's all ideology. Some people make money off of other people's work. NPM could turn evil. I don't care, at least not at this point. Wake me up when it becomes an actual problem in terms of "getting work done". I also disagree with the characterization that NPM really "owns" or "controls" anything. If they did something really bad, they could get replaced fairly quickly. Therefore, it's unlikely they will.
  - x3ro 7y ago
    It's interesting how you say 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc) 2) wake me up when it's an actual problem To me it seems like these two don't coexist well.. if it has become a "real" problem (whatever that means) then it'd appear that it'd already be too late to build a replacement solution, in your own logic.
    - gridlockd 7y ago
      > 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc) I never actually said that. It shouldn't take that long to get a package manager going. Also, there are already "alternative" package managers out there that one could switch to right now, should the need arise.
na85 7y ago
Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage. Seems to me that it is broke and needs fixed.
- jammi 7y ago
  The main issue with it is that it's too good and successful, therefore it's too easy to publish whatever crap as your library or its dependencies. That's not really a fault in the tool managing installation and publishing the library, its dependencies or managing the repository, providing the auditing system, script runner frontend and the other things npm does. You could similarly argue github is hot garbage, because there are so many crappy projects hosted on it.
  - kitd 7y ago
    It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.
    - hobofan 7y ago
      That's a fault of npm - _the registry_'s policies, not of the package manager. You could do the same with most other popular package managers if you have control over the registry.
      - icebraining 7y ago
        Sounds like you're agreeing with the Entropic people: https://twitter.com/bitandbang/status/1134872073896169472 https://twitter.com/bitandbang/status/1134872073896169472 Their approach is to create a different kind of registries, and inevitably they need a new client that supports them.
        hobofan 7y ago
        Yes, changing the registry model is key. I'm not quite convinced by their federated approach though. It feels like its just spreading out the problems, and not really preventing them from happening, and in the worst case even creating new ones. As pointed out in the talk, running a registry becomes expensive once it becomes popular. So now instead of 1 central registry (which I agree is not a good idea) needing to fund the hosting, you have maybe 10-100 federated registries, with each one of them needing to fund the hosting and coming up with different economic models around it. I'm also not sure how they would really be able to ensure immutability of packages in a federated system. A node could simply publish two different packages with the same name and version number to different parts of the network. Yes, you can reduce the impact by saving an integrity hash in a lockfile, but npm already does that today.
M2Ys4U 7y ago
>Don't fix it if it aint broke should be a motto for more developers. npm is broke, though. Better to have a replacement ready for when they finally go bang under the pressure of venture capitalism.
- lioeters 7y ago
  That's what I was about to say, that the current state of JavaScript package management is "broken" in certain aspects. The dependency on a private organization for open-source packages makes no sense. I think it's a healthy sign that we're starting to see more npm alternatives, decentralized package management protocol/standards. After some churn, may the best ideas win!

by jammi 7y ago

skrebbel 7y ago

> mostly irrelevant issues 95% of the talk is about why those issues aren't irrelevant. Care to respond to those?

gridlockd 7y ago
I think 100% of these issues are irrelevant in practice, 99.9% of the time. Sure, there was that "left-pad" thing one time. Sometimes NPM is down briefly. Otherwise, it's all ideology. Some people make money off of other people's work. NPM could turn evil. I don't care, at least not at this point. Wake me up when it becomes an actual problem in terms of "getting work done". I also disagree with the characterization that NPM really "owns" or "controls" anything. If they did something really bad, they could get replaced fairly quickly. Therefore, it's unlikely they will.
- x3ro 7y ago
  It's interesting how you say 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc) 2) wake me up when it's an actual problem To me it seems like these two don't coexist well.. if it has become a "real" problem (whatever that means) then it'd appear that it'd already be too late to build a replacement solution, in your own logic.
  - gridlockd 7y ago
    > 1) it takes really long to get a replacement of the ground (it's gonna be riddled with bugs etc) I never actually said that. It shouldn't take that long to get a package manager going. Also, there are already "alternative" package managers out there that one could switch to right now, should the need arise.

na85 7y ago

Most JavaScript-related threads I see on HN feature at least a handful of comments from people who will avow that e.g. the npm ecosystem is hot garbage. Seems to me that it is broke and needs fixed.

jammi 7y ago
The main issue with it is that it's too good and successful, therefore it's too easy to publish whatever crap as your library or its dependencies. That's not really a fault in the tool managing installation and publishing the library, its dependencies or managing the repository, providing the auditing system, script runner frontend and the other things npm does. You could similarly argue github is hot garbage, because there are so many crappy projects hosted on it.
- kitd 7y ago
  It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.
  - hobofan 7y ago
    That's a fault of npm - _the registry_'s policies, not of the package manager. You could do the same with most other popular package managers if you have control over the registry.
    - icebraining 7y ago
      Sounds like you're agreeing with the Entropic people: https://twitter.com/bitandbang/status/1134872073896169472 https://twitter.com/bitandbang/status/1134872073896169472 Their approach is to create a different kind of registries, and inevitably they need a new client that supports them.
      - hobofan 7y ago
        Yes, changing the registry model is key. I'm not quite convinced by their federated approach though. It feels like its just spreading out the problems, and not really preventing them from happening, and in the worst case even creating new ones. As pointed out in the talk, running a registry becomes expensive once it becomes popular. So now instead of 1 central registry (which I agree is not a good idea) needing to fund the hosting, you have maybe 10-100 federated registries, with each one of them needing to fund the hosting and coming up with different economic models around it. I'm also not sure how they would really be able to ensure immutability of packages in a federated system. A node could simply publish two different packages with the same name and version number to different parts of the network. Yes, you can reduce the impact by saving an integrity hash in a lockfile, but npm already does that today.

M2Ys4U 7y ago

>Don't fix it if it aint broke should be a motto for more developers. npm is broke, though. Better to have a replacement ready for when they finally go bang under the pressure of venture capitalism.

lioeters 7y ago
That's what I was about to say, that the current state of JavaScript package management is "broken" in certain aspects. The dependency on a private organization for open-source packages makes no sense. I think it's a healthy sign that we're starting to see more npm alternatives, decentralized package management protocol/standards. After some churn, may the best ideas win!