HN Theater @HNTheaterMonth

> This massively depends on the architecture of the package manager though. Composer (PHPs primary package manager) only serves the metadata

See also, CocoaPods. But we're really talking about two things here as if they're the same, and I think it's because the language we use for them isn't clear: package managers (like CocoaPods and Composer) and full-blown package registries (like RubyGems and NPM). I mean, the difference between them is slight; and there's overlap. They both resolve package dependencies and sort out problems, for example. But they're such very, very different things!

It's not really fair to compare these two approaches and say things about Composer like "this allows them to serve the whole community with a team of 2-4 people": they're just not directly comparable. Those 2-4 people + the entire GitHub staff is what supports the whole community.

Now - don't get me wrong: I think it's fine that GitHub does this! I'm not saying that CocoaPods and Composer are making the wrong choice here at all. In fact, I'm proud to work for a company that provides this service to everyone. But it hand-waves away a lot of stuff as just an "architecture" decision, when in reality it's a decision not to do the hardest part - which is hosting, because it requires gobs of money and dedicated staff and people on-call 24/7.

Framing it as just a different "architecture" implies that registries like NPM are making the wrong choices by hosting their own downloads, which I think is not nearly that simple. Because what happens if GitHub or Bitbucket decided to not allow this type of usage? It would be devastating for the community - so I think it's very appropriate for package managers to make a decision about whether or not they also want to be a registry. They're considering what could happen down the road and what that would mean.

CJ's comments on all of this, re: entropic, are really good: https://www.youtube.com/watch?v=MO8hZlgK5zc

For those wondering what's wrong with npm, I can recommend this C J Silverio talk https://www.youtube.com/watch?v=MO8hZlgK5zc

Sadly, as others have noted, this Pika thing does not quite address these issues.

There has been. CJ Silverio gave a talk on that topic at JSConf this year: https://www.youtube.com/watch?v=MO8hZlgK5zc

See also Entropic as a possible alternative to NPM: https://github.com/entropic-dev/entropic

⬐ tuananh

i doubt entropic will become sth significant. it already lost the momentum it seems.

⬐ pluma

For context: Entropic was started by several former npm Inc core developers including CJ who left the company after the CEO change was announced internally. CJ herself is the former CTO of npm Inc.

Basically most of the top developers have left the company, others were laid off. It seems to be only a matter of time until none of the people working on npm a year ago remain.

That is what happens when someone depends on VC money.

Regarding starting over, check

https://youtu.be/MO8hZlgK5zc

⬐ juststeve

wow that was a great video thank you

⬐ yarapavan

This JSConf EU 2019 talk by C J Silverio tells a story about who owns the Javascript language commons, how we got into the situation that the language commons is by someone, and why we need to change it.

Abstract:

The JS package commons is in the hands of a for-profit entity. We trust npm with our shared code, but we have no way to hold npm accountable for its behavior. A trust-based system cannot function without accountability, but somebody still has to pay for the servers. How did we get here, and what should JavaScript do now?

Transcript: https://2019.jsconf.eu/c-j-silverio/the-economics-of-open-so...

I am trying to understand why we make NPM such a big deal (and suddenly have all these projects born to solve the NPM problem) when people have solve the issue of a package repository already. C j Silverio's point (JSConf's talk [1]) was that is NPM's scale that makes it hard.

Refs:

1: https://www.youtube.com/watch?v=MO8hZlgK5zc

⬐ steveklabnik

To put some perspective on this, comparing Debian to npm:

Number of packages:

Debian has 172,000 packages for the most popular architecture, amd64. i386 has 24,000 packages. The rest have less than 500 each.

npm recently broke a million packages.

Download counts:

I couldn't find numbers for Debian. npm served 11.2 billion downloads last week.

(Debian numbers retrieved by https://popcon.debian.org/, npm numbers from https://medium.com/npm-inc/npm-weekly-200-dont-miss-today-s-... and https://api.npmjs.org/downloads/point/last-week

⬐ ricardobeat

Partially self-inflicted since a normal JS project will redownload the same packages over and over again, hundreds of times throughout their existence.

⬐ regularfry

Debian also has a repository model which allows the packages to be served by a static file server, because the dependency resolution is entirely client-side. Npm doesn't.

⬐ steveklabnik

Hm, as far as I know, resolution is also entirely client-side for npm. Do you have any links about this?

Here's the actual talk on youtube: https://www.youtube.com/watch?v=MO8hZlgK5zc

This is a great recent talk about this problem by the former NPM CTO in which she tells her story about NPM and proposes a new decentralized package manager:

https://www.youtube.com/watch?v=MO8hZlgK5zc

Also, have a look at the speech that C J Silverio gave about it:

https://www.youtube.com/watch?v=MO8hZlgK5zc

There's an essay version published here: https://github.com/ceejbot/economics-of-package-management/b...

And a video of the talk: https://www.youtube.com/watch?v=MO8hZlgK5zc

⬐ niklabh

This is the most powerful talk i have ever seen