Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.
I was very excited about the idea of workers but their tooling is (or at least was when I tried it last) abysmal, buggy and hard to understand. To this day I don't know how to setup a basic dev vs. production in workers.toml. Local debugging was buggy for naked domains (even found a GitHub issue for it that languished for months with no bugfix or clear explanation / workaround) and very slow.
Great idea killed by poor dev tooling.
Deno deploy is the opposite of that: deploys are instant and it's obvious how to deploy. You can develop and test locally.
Cloudflare released wrangler v2 (which dropped rust for node) and maybe it's better now but the one experience I had with wrangler v2 was trying to deploy a small static website (pages) and it failed due to their backend throwing 50x errors.
So much so that I wrote Denoflare (https://denoflare.dev/) to make writing Cloudflare Workers using standard Deno a breeze: no wrangler, toml, webpack, npm etc required
Competition is good.
https://deno.com/deploy/docs/pricing-and-limits https://developers.cloudflare.com/workers/platform/limits/
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...
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.
Even when CF open sources Workers, they will be useless for anything non-HTTP related.
> 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.
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.