I don't know if I'm getting old but this workers thing never clicked. Not just Cloudflare Workers but this concept of building a software on small bits of compute locked into a proprietary infrastructure.

If we had some "Open Worker Initiative" where I can build my software and then choose where I want to deploy it, it would sound ok. More or less like we handle containers.

It's fine IMHO to use this "worker" concept for simple bits of code that start and end in themselves, even if they are built upon a proprietary infra, like all the FaaS offerings out there. I just cannot imagine building a whole software on this model... but it feels like this is the concept being pushed to us.

Anyone here managed to make it work for them? How did you do it? Is it effective or you're thinking of going back to building your own blocks?

> If we had some "Open Worker Initiative" where I can build my software and then choose where I want to deploy it, it would sound ok.

To that end, two announcements from yesterday:

* Cloudflare, Deno, and others have formed a working group for serverless API standards. https://blog.cloudflare.com/introducing-the-wintercg/

* The Cloudflare Workers runtime will soon be released Open Source under the Apache license. https://blog.cloudflare.com/workers-open-source-announcement...

(Apologies that we don't actually have the code up yet... I'm working on it, there's a lot to detangle from our internal infrastructure, but it should be ready in a couple months.)

> small bits of compute

FWIW, there are some fairly complex applications on Workers. You can basically write arbitrary web apps. There is currently a 1MB-after-compression limit on code size for a single Worker, but we're working on increasing that.

I much prefer Deno's approach of using arbitrary ES modules hosted on the internet for composition, and was hoping CF Workers would move towards the same.

But here it looks like they're straying further from this approach in favor of another proprietary solution.