Back in the day, the way it integrated with Apache was an evolutionary advantage to PHP. It found a strategy that worked in its environment and it thrived. That environment no longer exists, but PHP holds on vestigially.
We didn’t have AWS or other cheap, virtualized hosting way back when. It was all shared plans where you had a directory of your stuff, and it was there with a hundred other people on the same server and Apache instance. You could run whatever you wanted as a CGI, but that was even worse; it forks off a whole interpreter for the language, parses the code, and then used STDIN/STDOUT to communicate. Even if you implemented it in compiled C code (which had all the other problems you would expect), that fork is still expensive.
Projects like mod_perl and mod_python built an interpreter directly into Apache, but there was a problem with how it worked: it was too sophisticated. They could hook into the entire Apache API. That meant that there was no way to separate your stuff from every other thing on the same shared hosting plan. Any one instance would be able to fool around in all other accounts. That’s untenable, so your choices for those languages were to either get a dedicated plan at well over $100/month, or stick with a $5/month shared plan and put up with it being unscalable.
Enter mod_php. It builds the interpreter into Apache, but that’s all it does. Still have a parsing step, but it doesn’t have to fork. Doesn’t try do anything else. Its fast, and it can be hosted on cheap shared plans.
If you’re a startup at this time, operating on frozen pizza and office chairs from a thrift store, then you could get a cheap plan, develop it under CGI, and hope that you can refactor it later when you can afford a dedicated plan. Oh, and keep in mind that CGI doesn’t lend itself to converting easily to the Apache API or whatever else you’re going to use in the future. Alternatively, you could build it in PHP and it will be fast now and acceptable later.
It’s no great mystery why PHP was chosen at the time. There were limited options, and it was the cheap, get it done now option.
Back in the day, the way it integrated with Apache was an evolutionary advantage to PHP. It found a strategy that worked in its environment and it thrived. That environment no longer exists, but PHP holds on vestigially.
We didn’t have AWS or other cheap, virtualized hosting way back when. It was all shared plans where you had a directory of your stuff, and it was there with a hundred other people on the same server and Apache instance. You could run whatever you wanted as a CGI, but that was even worse; it forks off a whole interpreter for the language, parses the code, and then used STDIN/STDOUT to communicate. Even if you implemented it in compiled C code (which had all the other problems you would expect), that fork is still expensive.
Projects like mod_perl and mod_python built an interpreter directly into Apache, but there was a problem with how it worked: it was too sophisticated. They could hook into the entire Apache API. That meant that there was no way to separate your stuff from every other thing on the same shared hosting plan. Any one instance would be able to fool around in all other accounts. That’s untenable, so your choices for those languages were to either get a dedicated plan at well over $100/month, or stick with a $5/month shared plan and put up with it being unscalable.
Enter mod_php. It builds the interpreter into Apache, but that’s all it does. Still have a parsing step, but it doesn’t have to fork. Doesn’t try do anything else. Its fast, and it can be hosted on cheap shared plans.
If you’re a startup at this time, operating on frozen pizza and office chairs from a thrift store, then you could get a cheap plan, develop it under CGI, and hope that you can refactor it later when you can afford a dedicated plan. Oh, and keep in mind that CGI doesn’t lend itself to converting easily to the Apache API or whatever else you’re going to use in the future. Alternatively, you could build it in PHP and it will be fast now and acceptable later.
It’s no great mystery why PHP was chosen at the time. There were limited options, and it was the cheap, get it done now option.