Not a monopoly, but it was the easiest and most performant option at lower price points.

Java required specialised or dedicated hosting ($$$). CGI was slow as hell. Mod_perl often was not available in shared hosting, for whatever reason.

PHP was cheap, fast, ubiquitous, and Good Enough™, for about a decade. Then VPS happened and the market changed.

Most people initially deployed php via CGI in my experience. I don't remember when mod_php arrived, but we'd been using PHP for quite some time at that point.

While CGI was slow-ish, alternatives like fastcgi were already around (and in fact running PHP via fastcgi was also quite common for a while.

By the time PHP became ubiquitous, most people had moved away from plain CGI regardless of language.

> in fact running PHP via fastcgi was also quite common for a while.

Mind clarifying how this is different from the current hotness (from what I can tell, due to a decade-old shortcoming that no longer exists in mod_php/Apache MPM options) where folks are running PHP via the Fastcgi Process Manager?

I don't think it is very different, other than hopefully maturity of the implementation. I've not had to set up any new PHP stuff for about a decade so I haven't kept up with what the current setups look like.

Re-reading it it sounds like it swung from fastcgi because Apache didn't have PHP support, to mod_php, and back to fastcgi (FPM) because Apache had poor concurrency support. It no longer does, but from someone who has to deal with this at their day job I can tell you that the current PHP ops wisdom is still stuck on not using mod_php.

The friction involved in getting those other technologies up and running was not trivial though. That played a role in php's initial success, because it was trivial to get up and running.

>The friction involved in getting those other technologies up and running was not trivial though.

That is only in relative terms in its time. For the past few years I keep thinking how the hell did Web Development went from Perl and CGI, arguably troublesome but understandable, to PHP which is ugly but easy to set up and running, to present days of... depending on which timeline you are, vagrant, VM, docker, k8s, Node.js... I would argue even Heroku with Ruby Rails isn't anywhere as easy as they were than the old days.

Indeed. I am much happier developing with Ruby on Rails than I was with say, PHP, but I do find it hilarious how back in the day deployment just meant uploading a couple of PHP files to a server and how now I need a full CI pipeline.

How so? As someone that's set them all up - with Apache the setup for mod_perl, php, and cgi are like the same right - they are all essentially cgi.

No, they are not the same as CGI. You can run PHP as a CGI, as many cheap hosts do, but for performance PHP is run as either Apache mod_php or php-fpm with Nginx. Mod_perl is not CGI and requires much more discipline to prevent shared memory leaks. Mod_perl allows content negotiation which CGI does not.

I remember it as a worse Perl, but with a bunch more web-batteries included. It's the latter that got me interested, way back in the day. Deployment story wasn't that different, aside from that cheap hosts were more likely to let you run PHP than Perl.

Coldfusion was also a thing around that time. Flash sites as well.

Yes, Flash was huge. When I was learning Perl around 2000 I shared a flat with a Flash animator who worked for an agency with huge clients such as Sky. It was all done in Flash for very big dollars.

Specifically to that point, Rasmus talks here about the reason PHP succeeded where Perl failed https://youtu.be/wCZ5TJCBWMg?t=552

I think rasmus's presentation explained pretty clearly why PHP won. Mod_php was a game changer and mod_perl failed by making the wrong choices. Overall, PHP was faster, easier, cutting edge and full of features without becoming too expensive to run, thats why web hosts supported it, not the other way around. What's not to love, honestly, even today.

https://www.youtube.com/watch?v=wCZ5TJCBWMg