movabletype VS wagi

Oh, weird. I was around before CGI scripts became commonplace on the web, and worked on a handful of projects in that space -- mostly in Perl, but also a bit in ColdFusion (shudder). I think there are some inaccuracies here, but didn't expect to read about someone exploring "old" CGI script technology today.

> CGI scripts mostly went out of fashion because of their limitations around performance.

Nah, performance was fine. It's mostly always been the case that the code running on the server isn't the bottleneck.

CGI scripts went out of fashion for several reasons that fall into the categories "too complex to maintain" or "there's this new thing called PHP...".

CGI scripts were often written in Perl, but also sometimes good ol' C, and occasionally some other oddball thing. But, Perl ruled the CGI script space. Over time, CGI scripts became more complex, as software often does. When people wanted something more than a simple mail-form, or a page visit counter, or a guestbook (remember those?), they'd often be faced with downloading, installing, and then maintaining a complex Perl application, which was a nightmare. Wanna see what a big Perl application looks like? Check out https://github.com/movabletype/movabletype.

Perl just didn't lend itself to well-structured code. I say this as someone who really liked Perl, TMTOWTDI and all that, and resisted moving away from it for years. But really, once your CGI script started spanning multiple .pl files, you were gonna have a bad time.

The other thing we didn't have was good templating. Handlebars and the like now just didn't really exist then. There were all kinds of ways to sort of gin up a templating system, but there were no standards and everything was homebrewed. This was really icky if you wanted to do something like make a site with a web editor -- forget all the wysiwyg stuff, just rendering the html in a clean and safe way and spitting it back out was a bit of a faff.

Along came PHP. It had a few advantages right out of the gate: (a) you could inline it in html, and I really can't overstate just how amazing that was at the time -- suddenly you didn't need templates anymore, you just used the html you already had; (b) it came with a good enough standard library of calls that were mostly comprehensible; and (c) contrary to Perl, which Perl hackers readily referred to as "line noise", PHP's syntax was pretty clean. (Younger developers may scoff at the idea of PHP being easier to read than any other language, but it was true at the time, and older developers may grumble that it was possible to write clean Perl, and that's true too, but it's also true that Perl culture encouraged and delighted at horrid and inscrutable gibberish.)

The one other thing PHP had going for it was mod-php, which was easy for sysadmins to install and worked right alongside mod-perl, which pretty much all of them knew how to install already. So, every little web host added support for PHP practically overnight.

> When a CGI script is executed, it initiates a new process for each request. While this approach is straightforward, it becomes increasingly inefficient as web traffic volume grows.

This is true, but largely irrelevant to why CGI scripts fell out of favor. Lots of people on-prem'd or colo'd their own stuff back then (I had a beige box on an ISDN once upon a time!), and it was really hard to get enough traffic to make a machine fall over because it was spawning too many processes. Usually your bandwidth would get saturated before that happened.

There was, maybe, a brief period where this was sort of a thing, where 56k modems were everywhere that DSL wasn't and people started to pay companies to run stuff for them, but even then -- as now -- the bottleneck was usually not in the number of running processes.

> Modern application servers like Uvicorn, Gunicorn, Puma, Unicorn or even Go’s standard server have addressed these inefficiencies by maintaining persistent server processes. This, along with the advantage of not having to bear the VM startup cost, has led people to opt for these alternatives.

Heh, heh. Some people may be using those because they read on somebody's blog that everybody else is using those so they should probably use those too, but I could become a wealthy man betting $100 to every dollar that any web dev who thinks switching from LAMP, php-fpm, nginx, or whathaveyou to Spangly Animal Server is gonna be their big performance win hasn't actually done a comprehensive performance profile of their application. You are burning waaaaay more milliseconds on your JS dependencies than you are on spawning a new thread.

Movable Type is written in Perl: https://github.com/movabletype/movabletype

WAGI and WCGI are the WASM based spiritual successors.

https://github.com/deislabs/wagi

https://wasmer.io/posts/announcing-wcgi

Compile a CGI program in any language to WASI, then use https://github.com/deislabs/wagi to run it.

Yeah of course! They've got STDIN/STDOUT/STDERR and I've built a Virtual Filesystem. But if you're using WASI binaries locally they don't have that restriction.

You might be interested in WAGI: https://github.com/deislabs/wagi

And to catch up on WASI: https://xeiaso.net/talks/unix-philosophy-logical-extreme-was...

As I'm sure you've heard, WASM has been growing in popularity and use over the past few years. And with the creation of WASI (Web Assembly System Interface) and WAGI (Web Assembly Gateway Interface), WASM is starting to venture outside of running just in the browser. And in the case of WAGI, if you've been programming since the earlier days of the internet, it might feel very similar to CGI programming (and that's because it's based on CGI1.1!) WAGI provides a way for developers to define handlers for HTTP requests and route them to specific functions inside of, or entire, WASM modules. It does so by piping the headers of the incoming request to os.Args[1:], piping the body of the incoming request to os.Stdin, and writing the response to os.Stdout. (To learn more about configuring, routing, compiling, and deploying WAGI routes, as well as the limitations of WAGI routes, please consult the WAGI docs and the TinyGo WASM docs)

What do you think of WAGI [1], which is basically CGI for WASM modules.

[1]: https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

as serverless functions (https://github.com/deislabs/wagi)

I'm experimenting with WASM & Rust but with a different framework named wagi, there's a great video by Rainer Stropek & Stefan Baumgartner that gives a little introduction to it [0]

[0]: https://www.youtube.com/watch?v=9NDwHBjLlhQ

[1]: https://github.com/deislabs/wagi

Krustlet and WAGI are two such projects.

It does support it, the runtime we are currently using enables that -- see https://github.com/deislabs/wagi/blob/main/docs/writing_modu...

Good point on the docs, I will open an issue and add some information about it, thanks!