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.
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.
> 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.
Most people, including small businesses, used shared hosting providers back then, and none of them supported mod_perl, while most of them eventually did support mod_php. That's why PHP came to completely dominate the market for self-hosted (or hostable) web applications, like phpBB, Drupal, and WP--writing those in anything other than PHP after mod_php became available (but before AWS) made no sense. PHP was at least as ubiquitously supported as Perl, and through mod_php (avoiding CGI's overhead), much faster.
Once mod_perl existed (it was late, after lots of CGI perl) - I feel that my clients and I never had significant difficulty in finding providers. PHP was all over the place - it felt - more because there was demand. But there was enough demand for mod_perl that it was always there when we wanted it. We never had to really hunt for a hosting vendor.
> I feel that my clients and I never had significant difficulty in finding providers
Yes, for professional uses. But we lost the next generation of devs. You could put PHP on any shared webspace and people started messing with it and from that messing, the next generation of open source PHP programmers came.
If you wanted to throw up a personal project using mod_perl you pretty much had to pay for a hosted box. At least once people realized how insecure it was to run shared code on a mod_perl host.
You could find hosts but it was comparatively expensive.
Plus it was a huge pain in the neck to do things like install the modules you needed on a shared host.
This was a huge barrier to entry and it made things unreasonably difficult. Meanwhile PHP was very low friction. And at the time, so many new people were teaching themselves web development to scratch itches and solve problems that these barriers were a big deal.
Which sucks, because mod_perl was amazing, beautiful tech.
> At least once people realized how insecure it was to run shared code on a mod_perl host.
People realized this immediately, given how much mod_perl exposed Apache's guts to script writers (so they could write modules in Perl--a feature few asked for, and fewer used) and how tightly coupled the two were, so much that calling Perl's humble 'exit' built-in became a notorious footgun (until, IIRC 5.6), terminating the underlying Apache process itself.
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.