[wwwigham]

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

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]

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.