The language itself is not that bad. Especially the newest releases are really great, thought out DX improvements. What stinks are its legacy parts and how it needs to be run.
My biggest pain is that for it to actually behave like it should it requires some sort of an actual web server like apache or nginx.
Also, servers written in are actually request handlers - every time a request comes, the whole app is reinitialized, because it just can’t hold its state in memory. In many apps every request means reinitializing connection with database. If you want to keep some state, you have to use some caching mechanism like redis or memcached.
Also had one time when Symfony app was crashing, because someone forgot to close class braces, and everything was “working” until some part of code didn’t like it and was just dying without any error.
And one time when someone put two endlines after php closing tag at the end of the file, confusing the entire php interpreter into skipping some lines of code - also without warning, and only in specific php version.
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.
The language itself is not that bad. Especially the newest releases are really great, thought out DX improvements. What stinks are its legacy parts and how it needs to be run.
My biggest pain is that for it to actually behave like it should it requires some sort of an actual web server like apache or nginx.
Also, servers written in are actually request handlers - every time a request comes, the whole app is reinitialized, because it just can’t hold its state in memory. In many apps every request means reinitializing connection with database. If you want to keep some state, you have to use some caching mechanism like redis or memcached.
Also had one time when Symfony app was crashing, because someone forgot to close class braces, and everything was “working” until some part of code didn’t like it and was just dying without any error.
And one time when someone put two endlines after php closing tag at the end of the file, confusing the entire php interpreter into skipping some lines of code - also without warning, and only in specific php version.
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.