They have the same service in a way: HTTP endpoint, email, cron, etc. You can edit your code on the same site, although I think that's much lower on their "features" list as compared to val.
Their answer to some of the questions you frame is simply "you dont".
No filesystem, use R2.
No source control, bring your own.
No containers, use wasm.
Sort of, but even Cloudflare workers went from a file editor to hosting an IDE-like environment (vscode) for your worker, and allows you to deploy worker "projects" directly from local/CI environments. Most Cloudflare Workers deployments I've seen were for custom proxies, or API transformation layers but nothing more complicated due to all the limitations, and it seems that's exactly what couldflare wants them to be used for, for now at least.
Not to mention that Cloudflare, despite their impressive services and scale, makes no profits. They don't publish details for Workers in particular, but I wouldn't be surprised if it's nothing but a blip in their overall negative income. They are also a public company so they are not beholden to VC influence per se or pressure to make profit on a short time scale. Their stock isn't doing well as a result. I personally have the sense that Cloudflare is playing a very long game and their board are ok with it. But I don't know if val.town or any small-time VC funded startup is playing the same 20/30 year game on becoming the de facto backbone of the internet the way Cloudflare is.
I agree, we have a lot of difficult questions to answer. (Founder of Val Town here)
Now we work well with small amounts of code, great for integrations, prototypes, internal tools, hackathon projects, home-cooked apps. You could think of us like "zapier for developers" or "retool but in code". Both of those companies built huge businesses without figuring out a lot of those issues. But we're hopeful we'll figure them out.
eddd-ddde is totally right that we're building a higher-level abstraction, like Heroku did, so we do avoid some complexity that way, and have better scale-to-zero economics, ie no need to lug around a whole file system for each runnable code.
The hard questions I'm currently focused on are working with groups of "vals" (ie folders or projects or some other abstraction), so you can fork, branch, and version them as a group. Part of me just wants to go back to files and folders and leverage git & github, but there's also something really powerful about live, rich, web objects, like tweets or a hacker news thread, that don't map well to files and folders. I really love this public discussion with some of my advisors and main investor about the tradeoffs of files & folders: https://github.com/val-town/val-town-product/discussions/106
We have a great investor (Dan Levine) who knows that these sorts of products take time. We have a small team (currently 4) which means on our current fundraise (5.5m) we have 3-5 years to figure some of these things out. If any of these problems sound interesting and worth tackling to you, we're hiring :)
They have the same service in a way: HTTP endpoint, email, cron, etc. You can edit your code on the same site, although I think that's much lower on their "features" list as compared to val.
Their answer to some of the questions you frame is simply "you dont".
No filesystem, use R2. No source control, bring your own. No containers, use wasm.