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
Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.
Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters
Correct - denoflare scripts are served in a permissionless Deno worker locally - even the Deno namespace is unavailable, just like on Cloudflare.
Developing the worker in Deno brings you the benefit of first-class support for typescript and ESM-modules in your worker, and no need for Node polyfills.
Once you deploy your worker, it runs like any other javascript worker on the magical Cloudflare V8 worker runtime.
Author here: yes this is exactly the goal of denoflare, I started it before miniflare existed, and Deno seemed much more aligned with the Cloudflare Worker model than Node, honestly.
With denoflare, you can serve your Cloudflare Worker script locally and deploy it to Cloudflare with a single tool, without the need for Wrangler, Node, NPM, or a separate bundler.
Also makes writing/deploying ESM-module-based workers trivial - can even deploy a CF Worker to your own account from a URL, e.g. [1]
thats really awesome. but why not update the docs to refelct that? they only mention "develop and test" locally. Are you afraid cloudflare will see this development as a threat?
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