movabletype VS blogs.perl.org

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

The nice thing about DEV is that I can republish the articles I published elsewhere (e.g. on PerlMaven, on Code-Maven, or blogs.perl.org), and also I can set the canonical URL of each article on DEV to the original one on my blog. That way I get the visitors on DEV as well, but the 'Google juice' the articles receive will flow over to my sites. It seems like a win-win for DEV and authors who have blogs elsewhere. You can even configure DEV to pull your RSS feed and create drafts from your articles published elsewhere. I even started to republish the content of the Perl Weekly.

That kind of solution has been up and running on the site for maybe as much as 15 months. (For context, the site has been under my stewardship only since March 2020.) Only, it’s insufficient: it works maybe 80%, but was broken in not just subtle ways. (#415 is the least of them, though the most obvious.)

Interesting thread.

Maybe take a look at this GitHub issue to catch up on what has been going on in that area. In particular, the comments from ap explain why it's not as simple as you might think it is.

If your motivation is to improve the public image of perl in general, then consider that for many questions, perl monks, a site that didn't look good 20 years ago, ranks high in search results. Never mind that the regulars on that site are not exactly inviting either. For blog posts, it's blogs.perl.org, which doesn't even have https in this day and age. My point being that if sites like these are still coming up in search results, it doesn't really matter how good metacpan looks.

Check out blogs.perl.org for tidbits other Perl people find interesting.

There's already an issue about this. I guess you could ask there to see what the current situation is.