Actually there is support for using WASM as a container runtime. You could in theory have WASM containers and Linux containers next to each other on the same K8s cluster. Not sure that I’d recommend it in production just yet, but it’s certainly usable
I think your comparison to CGI is unfair, since CGI in containers is quite different from "classic" CGI imo.
Wikipedia describes CGI as "In computing, Common Gateway Interface (CGI) is an interface specification that enables web servers to execute an external program, typically to process user requests.[1]
Such programs are often written in a scripting language and are commonly referred to as CGI scripts, but they may include compiled programs.[2]
A typical use case occurs when a web user submits a web form on a web page that uses CGI. The form's data is sent to the web server within an HTTP request with a URL denoting a CGI script. The web server then launches the CGI script in a new computer process, passing the form data to it. The output of the CGI script, usually in the form of HTML, is returned by the script to the Web server, and the server relays it back to the browser as its response to the browser's request.[3]"
Is it possible you don't have direct experience with CGI?
The typical way to deploy CGI during the '90s was to have a compiled program in C/C++, which would be executed once per request. There were entire frameworks built around this "process per request" model, with various optimizations like pre-warming (start the process, connect to db, wait for request on stdin) and variant protocols (SCGI).
Any time you have an execution model based on running a single address space per request, it's fundamentally CGI-ish. It doesn't have anything to do with the implementation language. The limitation of CGI is that state can't be persisted in-process between requests.
---
Going back to the thread, there's multiple aspects when thinking about the structure of a hosted service:
1. Whether state is shared between requests (CGI vs long-lived process).
2. Whether the binary is native code (x86/ARM/) or bytecode (WASM/JVM/).
3. Whether the binary is standalone or comes with additional files.
4. If it needs additional files, whether it's distributed as a package (apt/rpm) or chroot (container image).
Does breaking those different concepts down into a list help? You can see that trying to compare the performance of "WASM deployed as standalone binary with CGI execution model" and "native code deployed in container image" just isn't meaningful. The article is mixing up too many different ideas when trying to benchmark.
I ran PHP in CGI mode a long time ago if that counts :-)
I think what the article is implicitly doing is comparing WASM bytecode running under a container runtime that executes it directly (e.g., without a full chroot). Your point, iiuc, is that there are many variables here, of which x86 vs WASM is only one, and that the benefits here might not be due so much to WASM so much as they are due to the other factors.
I didn't understand where CGI-ness comes into it though, as I don't think there's any difference between this kind of container and any other in terms of the duration or when it's starter up, but perhaps your point is that it's lacking some "full" environment, which makes is akin to CGI? I guess a more accurate comparison would be against an x86 binary being executed with some kind of minimal docker runtime, then? I guess the article could be interpreted generously then as a comparison between a thin docker runtime and a thick docker runtime.
I guess that across the board vendors are experimenting and evaluating the impact of introducing WASM/WASI-based technologies and that may constitute something of a paradigm shift.
On the container side Docker also has native WASM support in a technical preview [0]. I don't think they see WASM as a threat, but rather as an addition to how apps and services can be delivered.
The other day I found an InfoWorld article "Solving the SBOM crisis with WebAssembly Components" [1] that features a diagram on the evolution of Application Development Stacks (by Cosmonic, one early adopter Wasm vendor) that indicates the trend. Idea is to tackle some of the complexity in current infra setups that have become like "Rube Goldberg machines".
Right now most early examples alas boot a container with a wasm runtime for each wasm instance, which is a sad waste. The whole advantage of wasm should be very lightweight low overhead wasm runtime instances atop a common wasm process. Having a process or container for each instance loses a ton of the benefit, makes it not much better than a regular container.
It's still being used to spawn a wasm processes per instance for now, but container runtime project Kuasar is already using the Sandbox API to save significant resources, and has already chimed in in comments on HN to express a desire to have shared-process/multi-wasm-instamxe runtimes, which could indeed allow sub ms spawning that could enable instance per request architectures. https://github.com/kuasar-io/kuasar
Some container runtimes (such as `runc`) execute a native binary. There are also container runtimes that execute a WASM+WASI binary.
So trying to compare WASM with "containers" is like asking "should you deploy your code as x86 or as a container", which isn't a useful question.