This is nothing to do with PHP the language. You can have an HTTP server and templating engine in any scripting language. It’s just the way that PHP is distributed is particularly easy. Someone could throw together a “PHPython” from existing components and get the same effect.
Yet, even with the actual deployment not being much different (just used Apache as an example here), there's still dependency management, which Python is often described to be pretty messy at, virtual environments or not. With PHP, most of the stuff you need for common use cases often is pre-installed and is just a matter of enabling some plugin in the config.
That said, I deploy most of my stuff in containers, so PHP, Python, Node, .NET, Java and others all become more alike when viewed from the outside.
Because it sucks! We tried it, it was bad, the Python community left it behind. Maybe if PHP left things that suck behind too then fewer people would say that PHP sucks.
The whole point of the parent comment was that it doesn't, at least when you want to be able to experiment and iterate quickly:
> It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it.
Why would that be a bad thing? Even when it comes to something like REPLs, everyone always touts being able to iterate more quickly as a good thing, don't they?
Edit: aside from the implications of an in process language runtime, that was discussed in another comment.
Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly? I can get up and running with a Python project in seconds and can iterate quickly with that.
“This is good because it enables you to iterate quickly” isn’t a good argument when you can iterate quickly regardless.
> Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly?
Necessary? Not quite.
But having those things be closer together leading to faster iteration? I'd argue that that's definitely true, same as how someone could skip out on writing a bunch of enterprise programming patterns, MVC or even tests, as well as use a language with a dynamic type system, or even write serverless functions. Not that any of that is very maintainable long term, but at the same time nobody would expect that from something that's very much like a REPL.
It's the same as how I like to have a clearly separated front end (typically a SPA) and a back end API (something RESTful) in most cases so that those technologies wouldn't be coupled and the API could be re-used as necessary, except that people who go for the various SSR and templating approaches typically code around me in circles, because they don't have to write as much API client code as I do.
> Because this method of deployment is not only unsafe but also doesn't scale.
How is a mainstream web server acting as a reverse proxy for an app server unsafe?
You get the benefits of one common approach to configuration, request logging (and possibly log shipping), rate limiting, compression, path rewriting and so on, while letting the app server handle the actual app and language runtime stuff (whether it's some Python app server, PHP, Java with Tomcat or whatever). You can even serve any static assets right there, alongside your API.
You can either include everything in a container, have separate containers for each process with overlay networking, or just have them run on the OS directly with only the web server binding to whatever ports you want to expose.
As for scaling, none of that prevents you from running anywhere between 1 or a million instances in parallel, with some load balancing (whether it's multiple servers or containers across a cluster). If it's really that bad, throw in HAProxy or something into the mix, alongside whatever cache solution tickles your fancy.
That's besides the point that I could provide a service to everyone in my country on a single rack (redundancy aside), not everyone even needs some mythical sky high scaling target.
> In the age of cloud, you just run your web application as its own server, a just have a proxy that fronts it.
Whether you use your own ingress (there's a lot of good ACME solutions out there) or something that your cloud provider gives you, using a server per app would in many cases be wasteful and there's a bunch of ways to increase the density, especially with the dynamic scheduling most container orchestrators could also give you.
mod_php runs in the same process as your http server, with the same rights. It's comically bad, especially in mutualized environments, and the reason why PHP is such a common target for hacks.
> mod_php runs in the same process as your http server, with the same rights.
mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.
Here's a very simple setup of two separate processes, with Supervisord (this is what runs in my self-contained dev container, but no reason why someone couldn't do something similar with systemd, or on a container cluster, with different users/permissions for each process):
> mod_php was great for local iteration or when you wanted a very simple setup (and the same could be said about mod_python etc.), but most people have moved over to PHP-FPM nowadays: https://cwiki.apache.org/confluence/display/HTTPD/PHP-FPM There's probably more recent information somewhere, but this pretty much covers it.
Or even simpler, just make your application listen to a particular port and implement a full HTTP server, and reverse proxy to that (or not) using whatever tech you fancy (Apache, nginx, Cloudflare, Cloudfront, ELB...)
This achieves the same thing while providing more control and layering standard protocols.
Oh but if your web server had PHP installed, it really was “easy” in a way that modern web programming is not. Yes, you could replicate it with Python, but actually you can’t, because no one has “thrown together” a PHPython. Nothing today can beat the feeling of being able to just drop a .php file in a directory and have an interactive, dynamic web page up and running
