workerd VS cloudflare-docs

WorkerD isn't anywhere near a "cutdown version of Chromium," it is an incredible platform with years of engineering put into it, from some of the people behind very similar and successful products (GAE, Protocol Buffers, to name some).

WorkerD is open source: https://github.com/cloudflare/workerd

I personally am not a fan of Deno because of how it split the Node JS ecosystem, so that is not a benefit in my eyes. Of course, Workers can run Rust.

Nothing you said here necessitates an API difference.

You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.

I've hit a bunch of issues and limitations with Wrangler over the years.

Eg:

https://github.com/cloudflare/workers-sdk/issues/2964

https://github.com/cloudflare/workerd/issues/1897

Workerd is a JavaScript & WebAssembly-based runtime that powers Cloudflare Workers and other related technologies. You can think of it like the Node.js runtime used to execute JavaScript files. Workerd has its differences from Node.js, however, you can self-host it on any machine.

Standards bodies only standardize things after they've been proven to work. You can't standardize a new idea before offering it to the market. It's hard enough to get just one vendor to experiment with an idea (it literally took me years to convince everyone inside Cloudflare that we should build Durable Objects). Getting N competing vendors to agree on it -- before anything has been proven in the market -- is simply not possible.

But the Durable Objects API is not complicated and there's nothing stopping competing platforms from building a compatible product if they want. Much of the implementation is open source, even. In fact, if you build an app on DO but decide you don't want to host it on Cloudflare, you can self-host it on workerd:

https://github.com/cloudflare/workerd

In any case, I welcome this initiative with my open hands and look forward all the cool apps that people will now build with this!

[1] https://pyodide.org/

[2] https://github.com/cloudflare/workerd/blob/main/docs/pyodide...

[3] https://github.com/cloudflare/workerd/pull/1875

For ref:

- https://blog.cloudflare.com/workerd-open-source-workers-runt...

- https://github.com/cloudflare/workerd

workerd

I think this is for people who want to run their own cloudflare workers (sort of) and since nobody wants to run full node for that, they want a small runtime that just executes js/wasm in an isolated way. But I wonder why they don't tell me how I can be sure that this is safe or how it's safe. Surely I can't just trust them and it explicitly mentions that it still has file IO so clearly there is still work I need to do customize the isolation further. But then they don't show any info on that core usecase. But then that's probably because they don't really want you to use this to run it on your own, they are selling you on running things on their edge platform called "Wasmer Edge". So that's probably why this is so light on information.. the motivation isn't to get you to use this yourself, just to use this their hosted edge platform. But then I wonder why I wouldn't just use https://github.com/cloudflare/workerd which is also open source. Surely that is fast enough? If not then it should show some benchmarks?

Yes: https://developers.cloudflare.com/ Look at Cloudflare Workers and Cloudflare Workers AI.

Cloudflare: Powers NuxtHub to provide various services

Cloudflare Docs

However, it's worth noting that modern tooling has made most of these challenges quite manageable. For NextJS specifically, projects like OpenNext are trying to de-couple the tight integration of NextJS and Vercel and making true NextJS self-hosting possible on platforms like Cloudflare and Netlify. If you don't mind losing some NextJS features by running it as a standard Node.js app, you can leverage tools like Docker and open-source PaaS alternatives like Coolify and Dokploy to make the experience of setting up a production-grade VPS much easier than doing things yourself.

Cloudflare https://developers.cloudflare.com

Slightly related - CloudFlare account_id and zone_id are safe to be public

https://github.com/cloudflare/cloudflare-docs/issues/474

https://community.cloudflare.com/t/api-zone-id/355566

> The Zone ID and Account ID are not sensitive. Sensitive data like account API Key, Secrets etc. can all be revoked, rotated or changed. See the comment 36 below on the Wrangler repo: as per our security team, it’s completely Fine to have your zone_id and account_id public, the Global API key and associated email address should be kept secret.

I have created an issue in their docs repository to address that misleading statement.

I don't strictly know if this is related, but the terms are being revised due to the release of R2: https://github.com/cloudflare/cloudflare-docs/issues/7186

CloudFlare cannot protect applications that use # in URLS: https://github.com/cloudflare/cloudflare-docs/issues/7062