As someone who dabbled with both workers and Deno Deploy: Deno Deploy actually works.

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.

Agree regarding tooling.

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

Yeah unless I'm missing something isn't this just a stand alone company offering roughly workers?

This is an open source JavaScript runtime with a hosted business model. Deno is great. Deno Deploy is a reasonable way for them to make money.

CloudFlare workers is on my radar because of an ecology of other "edge" products that are in the works or already released. That's what Deno would need to catchup on to be on the table for discussion for me. Otherwise it remains a toy I use in my spare time (which I do enjoy at the moment).

Meanwhile, Cloudflare says they are open sourcing Cloudflare Workers runtime: https://twitter.com/KentonVarda/status/1523666343412654081

You could say the same about AWS Azure, and GCP.

Competition is good.

Competition is great - sure, but I want to know what Deno gives me over its competitors.

Workers are not meant as a generalist runtime.

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.