To get Perl to work with apache (the most used web server for a time), there were two options: the not-so-complicated cgi script which gets executed from scratch on every request, then there was mod_perl which required a lot of tinkering with apache configurations and writing your code in a different way.

Even with those two options, you can't just write some code in a page and execute it without some sort of itermediate code.

Thats why php became so popular, perl coders could pick it up in a day ($ and all) and all you have to do is write .php files to a server - with the bonus that you have a rudimentary templating system built-in to php.

There really isn't much more to it than that.

I vividly remember the first time a friend showed me PHP in the late 90s. You're saying I can just write a script that generates HTML and throw it in /foo/index.php and that's the whole thing?

It's wild that right up until Rails got popular, we were writing code that served billions of requests off of homebrewed MVC-ish PHP frankenframeworks.

> mod_perl which required a lot of tinkering [...]

Here we used mod_perl all over the place and it was glorious. It did take understanding how to use it - well, yes - same as the rest of perl (or apache for that matters). But it was so well integrated! I still miss it.

"Picking it up in one day" is not a criteria for professional deployements.

This is why I preferred Mike Migurski’s nickname for PHP: Apachescript; easy to integrate to the web server and next fastest thing to C for Apache.