I think you're right, but I think the key part of the tech is economic: their ability to deploy hundreds or thousands of instances safely shared by large numbers of replicated sites and applications belonging to different site owners.

Individual site owners can't afford that level of infrastructure for each site separately. Actually deploying it isn't that difficult, it's just expensive and unjustifiable.

(I nearly started a business doing what Cloudflare Workers is doing now, about 10 years ago (and not with JS/Node), so I know a fair bit about building out this sort of distributed edge system, including the WebSockets and anycast part. But life took a turn and IPv4 blocks for anycast were starting to look a bit beyond what I could justify for the development, even back then. In retrospect it would have been a good thing to build.)

> That is, if the decentralized web fails to take off in the next 5 years.

You have given me an idea :-)

(For a side project I'm working on zero-knowledge proofs of execution, which allows nodes to execute code on behalf of other nodes without the latter having to trust the former. Performance is far too slow to run things like websites at the moment, but there are many tricks for speeding it up, including hardware acceleration.)

No, it wouldn't, that's a misconception. The Perl system I described ran fine on however many servers you wanted to run it on, like any horizontal scaling system. Pretty much anything that runs in a container and isn't required to communicate with a central database does. The design based around indexing files and caching calculations is effectively stateless; it scales without limit if you have the servers.

Any specific points of global data consistency require communication with a shared data store of some kind, but that's also true in Cloudflare workers, where there's a separate Durable Objects system for that. Cloudflare's Durable Objects is pretty good as those things go, but that's not what your comment was about.

What's impossible for most is paying the cost of hundreds of locations. And if you really want to do it well, anycast IP blocks. But if you have the servers, and don't need every request to fetch from a central database (or can use an eventually consistent distributed one), there's no problem deploying as many instances as you want with something that's effectively stateless, even if it's Perl, Python or PHP.

> what usually happen is that the scripting language creep start getting bigger and bigger until it's unmanageable.

Probably right, but I'm curious why you think there won't be equivalent JavaScript creep in sites using CloudFlare Workers.