[muglug]

> its request model is still based on CGI, executing a script for each request

And it turns out to work incredibly well for the most part. It's serverless by design!

> People are still relying on a webserver to rewrite URLs because PHP doesn't have the concept of an application server with a router

Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.

[jchw]

>And it turns out to work incredibly well for the most part. It's serverless by design!

Worked incredibly well compared to what? CGI was a performance nightmare, forking per request. CGI and FastCGI have both been a security nightmare. HTTPoxy, Shellshock, Pathinfo, and more. Setting up PHP correctly is cumbersome and depends on a complex interaction between sometimes confusing php.ini options and fairly complex configurations with your webserver. Check out, for example, this article on configuring PHP properly with Nginx:

https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-an...

So other than that, yes, it worked. Incredibly well? Not compared to application servers which don't have the kinds of vulnerabilities and configuration complexities caused by the weird impedance mismatch between webservers and FastCGI workers.

The jab about serverless is really condescending and unrelated, but I feel it necessary to point out that I am not really especially a proponent of serverless as it is today. I much prefer long-running application servers. PHP-FPM gives you a bit of both worlds, a combination of them that is far from ideal in my opinion.

>Again, I don't see how this is a problem. Routing is likely to be the most trivial part of your app, but it's also tied to business logic and should (IMO) be part of the checked-in code.

I am having difficulty responding to this because I think you misunderstood what I meant. I do think the routing logic should be part of the code. Which means, not part of the webserver configuration. If you're using Nginx, which is the server I currently use with PHP, checking your rewrite configuration in with your code is difficult, because there's no `.htaccess` mechanism like Apache, and so you have to deploy the configuration separately.

[muglug]

> Setting up PHP correctly is cumbersome and depends on a complex interaction

One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

> If you're using Nginx

I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

The point I'm trying to make here is that for most web request use-cases, PHP can help you get what you want. But if there's a paradigm you prefer, use it. If you control the stack, the world is your oyster.

Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

[jchw]

>One of the reasons PHP is so successful is that (in most cases) you don't have to set it up beyond the default installation. But when you need something done "correctly" it takes time. The same is true for every other server environment, where what's correct for you isn't necessarily correct for me.

I disagree. I think PHP was so massively successful because it was part of the mighty LAMP stack. The LAMP stack wasn't great because it was free of configuration, it was great because anyone could pick up an existing setup and just use it. A non-technical person could get a Bluehost or Hostgator account and get Wordpress running in under an hour.

But once you move from shared hosting to VPSes, the plug and play fun goes away. At reasonably moderate traffic, you have to tune things and debug weird issues. And debugging it, in my experience, is actually very challenging.

The best part of the LAMP stack today is that it offers a very quick way to get a good development environment. Since scripts are read off the disk, you get "auto reload" for free. That is nice, but given how mature other development environments have become, it's no longer a huge selling point to me.

Is the ease of use of the LAMP stack worth the negatives of PHP as a programming language? In my opinion, no. To me, it's only really 'yes' if you already have a very large PHP application, or you are writing software for people running LAMP stacks to deploy.

>I don't have any experience using PHP with Nginx - we use Varnish at $dayJob, alongside some very basic non-PHP routing e.g. foo.domain.com goes to one set of servers, bar.domain.com goes to another. Everything else is done in PHP, with a simple wildcard .htaccess pushing everything to that front-controller you were talking about.

If you're using .htaccess, it sounds like you're probably using Apache as an HTTP server. Varnish is a caching server.

>Edit: the article you posted is from 2011. It's not entirely fair to say PHP is bad, and use evidence from 7.5 years ago to back up your claim.

I never said PHP was bad. I am making the case that the application server paradigm where you have long running programs handling requests is better than the CGI and Fast-CGI paradigms where you run scripts per request. You can put band-aids on it, like caching very aggressively, but at the end of the day you will never get the 'free' amortization of per-request costs like you will with a proper application server.

That said, I totally think it's fair to use evidence from 7.5 years ago. A, these configuration difficulties exist today, and my proof is that I also have them today. B, Track record matters! PHP and PHP-FPM have been around for decades. Having constant security issues is a sign of endemic issues, such as what we saw with software like Wordpress or Drupal.