JSR Is Not Another Package Manager

Based on similar experience from other language ecosystems since Perl introduced CPAN, unless a customer requires me to use JSR, I am not rely convinced to stay away from npm repos.

What's the business model, I wonder? The reason npm registry didn't evolve much is that it is expensive to give away cloud services and eventually got sold to Microsoft, who presumably assessed that adding features wouldn't drive much extra revenue. How many people publish private packages to npmjs.com how much does it cost to host and serve the ever growing collection, especially as they're pretty lenient about people serving large binaries from it?

The Java world got burned by this a few years ago when JFrog shut down Bintray, which had been the second largest open source package repository after Maven Central. A ton of stuff had to be republished, a ton of build configs updated. Now Maven Central is hopefully Too Big To Fail and Sonatype is a sustainable independent business, partly due to the widespread practice of companies buying its Nexus product to mirror Central internally, something I haven't seen so much of in the JS space, and partly because the Java ecosystem doesn't tend to host giant binaries off it. But still.

Gotta admit, I'd like to see a more decentralized approach become popular here. There's no specific reason packages always have to be hosted in one or two central registries.

Sure, it's not a "Package Manager" by JavaScript nomenclature, where apparently the package manager refers only to the client side piece. Instead it's apparently a "Package Manager" and a "Package Registry"… which most other environments just call a "package manager".

As a non-JavaScript developer, drawing this distinction feels incredibly silly to me…

>Gotta admit, I'd like to see a more decentralized approach become popular here. There's no specific reason packages always have to be hosted in one or two central registries.

That is what ESM is. Each https link are basically decentralised registries.

> What's the business model, I wonder?

Serverless functions, right? That's what deno deploy is billed as. Presumably the registry is a platform-adjacent investment to try and bring more serverless market-share to deno. Since it provides a npm-registry compatible facade, presumably you should feel safe publishing deno-y code to it (without calling platform APIs?), and should thus be more likely to use deno, and thus enter the funnel for deno deploy.

Personally, I just use deno's rust v8 wrappers a bunch, since they make embedding a V8 runtime into a rust app very simple, and js is a very nice scripting engine (especially with optional types). A hugely valuable contribution to the open source community. But then again, I don't deploy serverless functions on the regular. To each their own.