With CGI the developer of the script could pretend that the-only-thing-which-existed was this request and do all kinds of things that would bring down a persistent process (leak memory, mutate globals, etc.) The problem was that spinning up a process per-request was expensive and slow. Now, with WASM's memory model it becomes possible to have a process that both does all the slow work initialization work once and has the ease-of-reasoning properties of CGI's "a single process for a single request" serving model.

Edit to say: thanks for your answer. I'll preserve the rest since I still think wheels are being reinvented here.

Bridging state across requests is not new. If "the new CGI" means more efficiently sharing state between requests, that's a really arbitrary qualifier and is not unique to WASM or serverless or anything like that. The article is myopic, it doesn't take into consideration what is established practice done over and over.

WASI CGI is the new CGI. :-)

https://codeberg.org/valpackett/caddy-wasm-wcgi

Sorry, I'll use this rare opportunity to bring up WCGI for Caddy. :-) It is a Caddy web server plugin that runs CGI applications compiled to Wasm, which includes scripting language runtimes. The project isn't mine, and I haven't tried it for anything beyond a "Hello, world!". I think it is a neat hack.