Neither is Deno Deploy, really. The limits on CPU time etc are very similar, with Cloudflare being more flexible on CPU and Deno Deploy being more flexible on bundle size.

https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/

Yes Deno Deploy is for HTTP (just like CF Workers) but my point is that Deno is more of a generalist runtime compared to Workers and has a much broader appeal than just Deno Deploy.

Here's an example. Deno is like any other backend runtime and has regular DB clients. CF Workers do not. If you want to use Workers with PG, the CF docs point you to Supabase which provides REST over PG using PostgREST.

https://developers.cloudflare.com/workers/tutorials/postgres...

Yes, Cloudflare Workers originally couldn't make arbitrary outgoing TCP connections. Cloudflare wrote an adapter to transport Postgres over WebSockets (https://blog.cloudflare.com/relational-database-connectors/) and then added support for TCP connections (https://blog.cloudflare.com/introducing-socket-workers/).

Deno Deploy doesn't have much of a moat, and Cloudflare is better funded. Both are promising to be open source & self hostable (https://twitter.com/KentonVarda/status/1523666343412654081). We shall see.

I'm arguing about Deno (the whole thing) vs Workers, not Deno Deploy vs Workers.

Even when CF open sources Workers, they will be useless for anything non-HTTP related.

Grandparent said

> Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.

Note "their service". You replied with

> Workers are not meant as a generalist runtime.

So, we really were talking about Cloudflare Workers vs Deno Deploy.

Deno is something different, for sure. But it seems Deno Land Inc. is betting on Deno Deploy. Which makes grandparents' question interesting.

With all due respect, there's a point I think you're missing here.

What I'm saying is that, even if you're only going to use Deno Deploy, it is an objectively better proposition because Deno (the runtime) has a much broader use case.

Would you rather use something that (for now) can only be used on a single cloud provider for (let's call them) "edge HTTP" workloads and integrations with services of that single cloud provider...

... or use something that can be used on any cloud/hosting provider, for any HTTP workload (plus many other non-HTTP use cases), which also happens to have an "edge HTTP" service custom tailored for it?

And let's not forget, Deno (the company), is much more focused on real developer needs. Workers still have a mediocre DX (although it has improved considerably lately) and still no framework for Workers like Fresh.

https://fresh.deno.dev/

I'm happily deploying Deno projects to Cloudflare Workers. Outside of Deno.* (not like any isolate-based serverless thing has processes or files), it's all APIs specced by browsers.