Totally agree there, the article makes complete confusion between the execution model and the tech used to execute. Especially since it says « not CGI as the protocol but as the model ».

As far as model goes, the serverless one is not a different model. It is still a flavor of the CGI concept. But the underlying tech is different. And not that much. It is only serverless for you as a customer. Technically speaking, it runs on servers in micro-VMs.

Those are orthogonal matters, and even if such tech as the middleware mentioned get some wind, the execution model is still the same and is not new.

The use of wasm makes sense to me in context of the article.

The article does not seem to support the title. You'll have to show me how it does. 'serverless' is a wholly different concept that doesn't have much to do with wasm. You could say it's CGI as a service, but that has nothing to do with wasm.

It's quite buried amid a lot of extra paragraphs expositing about WASM and the future of serverless functions in general, but the article does contain this quote:

> One of the many effect of how [WASM] modules are isolated is that you can "pause" a module, and save its memory as a data segment. A similar concept to a Snapshot of a virtual machine. You can then start as many copies of the paused module as you like. (As I tell friends, it's like saving your game in an emulator.)

> The snapshotted module has no extra startup time ...

> If we go back to thinking about our Application Server models; this allows us to have a fresh process but without paying the startup costs of a new process. Essentially giving us CGI without the downsides of CGI. Or in more recent terms, serverless without cold starts. This is how Wasm is the new CGI.

This is not like CGI. Calling it "the new CGI" seems to me like a way to confuse people, since CGI was a response to individual requests and carrying state across requests was always extra work. None of this has to do with WASM in particular.

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.

You might have missed wasi