I think it’s because the experience of familiarizing oneself with the platform and getting to a hello world level crud app/basic static site is done a lot better with vercel and netlify than it is with cloudflare. Cloudflares site and docs are not built with the approach of getting an app from 0 to 1 ASAP.
I get the sense that Cloudflare Workers is targeted almost exclusively at existing customers of Cloudflare, who have a “legacy” app proxied through Cloudflare DNS, who use Page Rules and Firewall Rules and the like.
For these customers, Workers are an incremental optimization of an existing app — shifting some work to the edge, or allowing some systems to have a previously-internal backend stripped out, leaving them as e.g. Workers in front of an object-storage bucket. And that’s exactly how Cloudflare advertises them.
It looks like Cloudflare’s outreach advertising, meanwhile, is all about CF Pages and CF Sites. You can find SEOed landing pages for these; whereas Workers is mentioned ~never in external media as a “solution” — even though it totally can be.
Workers started with that use case, but these days we're definitely aiming to be a general-purpose platform for app hosting, especially for new apps. It sounds like we're not getting that message across very well.
Not just the message; the docs, and even the internal structure of the Workers section of the CF dashboard, are also lacking on describing how to approach building a greenfield app using Workers.
I recently tried to build a Worker-based app for a personal project, after a few months of not having touched Workers, having only previously used them at $work for the "decorator of legacy backend" use-case. I knew what capabilities Workers had, and knew exactly what I wanted to do... but getting it up and running was still confusing!
One specific example: trying to figure out how to get a production-quality workflow for maintaining and deploying a worker.
- It's actually hard to notice the "Edit Code" button on a Worker's overview. I flipped through all the other tabs twice before noticing it.
- Then, after getting in there, I remembered how useless the web IDE is for testing, when the domain is fronting a bucket named after a custom domain associated with a Workers Route rather than with the canonical name of the worker. So I wanted to set up the worker to deploy from a Github Action.
- But how do I do that? Can I go into "Integrations" and select "Github Repo"? (No.)
- I figure that the Wrangler CLI will set me up for doing on-push deploy. So I download it. (It doesn't.)
- Also, the CF Workers docs tell me to install the wrangler NPM package and run `npx wrangler init`. But once I do, that command itself tells me that it's deprecated, and that I'm supposed to run `npm create cloudflare\@2.5.0`.
- I read through the Wrangler docs and figure out that it's a "build a local slug from your worktree and push it" kind of deployer, rather than a "build a deploy from a git ref and push it" kind of deployer. So I figure, to enable GitOps deploys, I'll need an action that runs Wrangler itself on Github Actions. I search the Workers docs, and the Wrangler CLI docs (separate site) for this. Neither one mentions this possibility.
- I end up just googling "wrangler github action" and finding https://github.com/cloudflare/wrangler-action. Great! I add it to the new Github repo that Wrangler created, and add the relevant secret.
You know what this could have been instead? A button on the Workers dashboard — or even on a CF marketing landing page! — that 1. SSOs the user into Github; 2. automates the creation of a new repo that gets pre-populated with a Worker skeleton project + this Wrangler workflow already committed to it + the correct relevant secret already bound into the repo; and then 3. drops me into either the Workers IDE (modified to connect to the repo by creating PR branches + committing to them for "drafts", and merging those PRs for "publish"), or alternately, into Github Codespaces with the Workers IDE stuff reimplemented as a VSCode preview plugin. (And same for Gitlab, etc.)
Pricing also.
0.40 USD / month for a globally deployed site @ CF versus 199 USD / month for a static site with limited traffic usage @ the supposedly premium other hosts
