4 ms·

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 M

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.

eviks 3y ago
Why isn't "just one build script/config you don't need to update" not a specific reason for a central registry?
vmfunction 3y ago
>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.
- hobofan 3y ago
  That's what Deno's interpretation of ESM, but nothing inherent to ESM. The ECMAScript standard doesn't specify the "ModuleSpecifier" further than a string, so how the module specifier is interpreted and loaded may range anywhere from "a handful of well-known modules" to "any retrievable URI".
wwwigham 3y ago
> 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.
- chrisldgk 3y ago
  I believe you hit the nail on the head there. That, together with the fact that you can still host the deno runtime on your own hardware actually makes it a pretty viable alternative to new projects that you would be building using NodeJS otherwise, with the added bonus that if you ever decide to go serverless, you don‘t have to rewrite your code since you can take the same codebase and move it to deno deploy (or supabase functions, which just uses deno under the hood itself)
  - chrisweekly 3y ago
    FTR a large and rapidly-increasing percentage of the JS ecosystem supports targeting multiple runtimes. Things like Remix.run, Fastify, Hono, etc. can deploy to Node.js, Deno, Cloudflare workers, etc.
chrisldgk 3y ago
While I haven’t tried it myself yet, I remember finding nest.land[1] and thinking decentralization is a beautiful approach to something as centrally important to the JS development world as packages are. I also remember thinking it‘s the first and only thing I‘ve ever seen where using the blockchain as the technical basis for it makes sense and isn‘t tacked on for grfiting purposes. [1] https://nest.land https://nest.land
- fire_lake 3y ago
  Who pays for hosting? The site claims it’s free but I read that as unsustainable
norman784 3y ago
> What's the business model, I wonder? I think this video[0] answers that question, overall I think the video is interesting if you have time to watch it entirely. [0] https://youtu.be/dHfZiqVWVhk?si=RqEmPmizm7Rs_91V&t=2779 https://youtu.be/dHfZiqVWVhk?si=RqEmPmizm7Rs_91V&t=2779
pjmlp 3y ago
We also use Nexus for .NET, C++, nodejs stuff. Decentralized approach mostly matters for having a curated repo of what teams are actually allowed to use on their projects, instead of having legal surprised by random devs downloading the Internet into their projects.

eviks 3y ago

Why isn't "just one build script/config you don't need to update" not a specific reason for a central registry?

vmfunction 3y ago

>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.

hobofan 3y ago
That's what Deno's interpretation of ESM, but nothing inherent to ESM. The ECMAScript standard doesn't specify the "ModuleSpecifier" further than a string, so how the module specifier is interpreted and loaded may range anywhere from "a handful of well-known modules" to "any retrievable URI".

wwwigham 3y ago

> 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.

chrisldgk 3y ago
I believe you hit the nail on the head there. That, together with the fact that you can still host the deno runtime on your own hardware actually makes it a pretty viable alternative to new projects that you would be building using NodeJS otherwise, with the added bonus that if you ever decide to go serverless, you don‘t have to rewrite your code since you can take the same codebase and move it to deno deploy (or supabase functions, which just uses deno under the hood itself)
- chrisweekly 3y ago
  FTR a large and rapidly-increasing percentage of the JS ecosystem supports targeting multiple runtimes. Things like Remix.run, Fastify, Hono, etc. can deploy to Node.js, Deno, Cloudflare workers, etc.

chrisldgk 3y ago

While I haven’t tried it myself yet, I remember finding nest.land[1] and thinking decentralization is a beautiful approach to something as centrally important to the JS development world as packages are. I also remember thinking it‘s the first and only thing I‘ve ever seen where using the blockchain as the technical basis for it makes sense and isn‘t tacked on for grfiting purposes. [1] https://nest.land https://nest.land

fire_lake 3y ago
Who pays for hosting? The site claims it’s free but I read that as unsustainable

norman784 3y ago

> What's the business model, I wonder? I think this video[0] answers that question, overall I think the video is interesting if you have time to watch it entirely. [0] https://youtu.be/dHfZiqVWVhk?si=RqEmPmizm7Rs_91V&t=2779 https://youtu.be/dHfZiqVWVhk?si=RqEmPmizm7Rs_91V&t=2779

pjmlp 3y ago

We also use Nexus for .NET, C++, nodejs stuff. Decentralized approach mostly matters for having a curated repo of what teams are actually allowed to use on their projects, instead of having legal surprised by random devs downloading the Internet into their projects.