PHP opened the door to cheap web dynamic web hosting and in turn you had self-hosted applications like Wordpress. It was a few years later that languages like Java and C# became really attractive for back end work, you also had Ruby, Node, etc.
I wrote a lot of PHP in the early 2000s because that is were the work was, thatβs what you could write open source code that people would use in, and it was really straightforward to build apps (like a social network for a secret society) without an βopsβ team watching your every move.
I've only done PHP for small personal projects and some wordpress hacking, and that was years - so my experience is limited. But it seems to me that one of the great and tragic things to PHP is the low barrier to entry. As you put it: "first open source language in which just anybody could write server-side web applications without terrible management problems for the sysadmin".
This made it extremely easy for anyone in the early 2000s who signed up for a web hosting account on godaddy/hostmonster/hostgater/etc... to fire up a text editor of their choice and start slinging code and FTP'ing up to a server. Didn't have to worry about installing, configuring, all the dependencies, build tools, etc... just edit, upload, refresh -- lather, rinse, repeat until it works. Lowered the barrier to entry, and got a lot of people into the field. Really powerful stuff.
It also made sloppy, hacked-together, copy-pasta code very prevalent. In my limited perspective, I suspect that this prevalence of sloppy spaghetti-code has contributed to PHP's bad reputation. It's not that you can't do good code (totally can!), but a PHP environment can be forgiving of some pretty bad practices.
PHP has a low barrier to entry, but that's a great thing in my opinion. It's something that should be celebrated, and at the very least, it shouldn't be a criticism!
Bad developers exist in every language, and no language is completely wart-free. People just like to zero in on PHP to criticise it because it's easy, and it bugs me a bit (especially if they're simultaneously singing the praises of another less than perfect language such as JS or Python or Go).
At that time you could have made similar software for JSP, ColdFusion or ASP.NET but hosting would have been much more expensive and a big hassle. With PHP it was feasible to offer a $5 a month hosting plan good enough for blogs and simple web application.
I wrote a lot of PHP because it was a great way to deliver products to customers, particularly ones that didn't have a lot of resources for "ops" but also a place where I could write open source software which might really get used and have an impact.
I don't recall the sequence of events that way. That is, there was regular cgi, then mod_php with problems similar to mod_perl...then later fastcgi options existed for both.
What's the newer fastcgi php method that isn't mod_php?
FastCGI is a protocol that allows a web server to communicate with external programs that provide dynamic content, such as PHP scripts. In FastCGI, the web server launches an external program, called a FastCGI process manager, which is responsible for starting and managing a pool of long-running PHP processes. When a request for a PHP script comes in, the FastCGI process manager assigns one of these processes to handle the request, and the process generates the dynamic content and sends it back to the web server.
mod_php, on the other hand, is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that PHP scripts are executed directly within the Apache process, without the need for an external process manager.
While both FastCGI and mod_php are ways of running PHP on a web server, they differ in their implementation and how they handle requests for PHP scripts.
Deploying to the cgi-bin directory was more convoluted and error prone for end users. Even when you did it right all of your URLs had an "ugly" cgi-bin component.
The easy deployment and cheap shared hosting with their managed MySQL instances really helped boost PHP's usage.
> Write an explanation for the user who posted the following comment: "Wait. Isn't fastcgi essentially the same as mod_php? IPC with a long-running process rather than forking and capturing stdout? What's the newer fastcgi php method that isn't mod_php?"
is:
> FastCGI and mod_php are similar in that they both use a long-running process to handle PHP requests, rather than creating a new process for each request. However, they differ in how they are implemented and how they interact with the web server.
FastCGI is a protocol that allows a web server to communicate with external programs, such as PHP, to handle dynamic content. It is typically used with web servers such as Apache or Nginx. In the case of PHP, the web server uses FastCGI to send PHP requests to a PHP-FPM (FastCGI Process Manager) process, which then executes the PHP code and returns the result to the web server. This allows the web server to handle multiple PHP requests simultaneously, improving performance.
On the other hand, mod_php is an Apache module that embeds the PHP interpreter directly into the Apache web server. This means that Apache can handle PHP requests itself, without the need for external programs or FastCGI.