I don't know for big instances of Laravel, for every deployment pipelines of Symphony I've seen were far from "Drop that file on the server. The end."

In the most primitive ways, you would at least do cache warming, which usually means "building" the app instance in a separate folder and swapping the active directory served by the web server. That's basically what a basic Capistrano deploy would do.

Nowadays I'd expect most shops to be using containers for PHP too, and that means building your container like any other language.

What I'm saying is, the days where PHP deployment was simple have been long gone, for at least a decade in my experience.

Ruby did have such a thing, via mod_passenger, and other options were available for different scripting/programming languages.

Back in the day PHP got big because most of the larger shared-hosting sites provided mod_php out of the box, along with MySQL.

If you wanted to run CGI scripts you were probably capable of doing that, whether in Perl or something else, but most of the other options came later or were unusual.

I know when I tried to setup a few sites a long long time in the past I had to get a VPS of my own, with root, to configure Apache appropriately. None of the shared hosting sites would have run the kind mods I wanted to have.

They do. It's just that everyone seems to have collectively decided that cgi shouldn't be used anymore.

CGI has become "serverless" and it's hyped up to no end. The more things change, the more they stay the same.

Thanks for the comment!

I think the "the more things change, the more they stay the same" is a great thing, and something to very much be aware of and study. The move back and forth from backend state to frontend state to slim apps to fat apps has been going on since the 60ies, and is driven by ultimately hardware and networking costs.

The underlying patterns are all fairly well understood, which means that knowing both approaches and being aware that things are going to slosh back and forth heavily simplify long term design.

I haven't written these thoughts out, but in many ways the codebase (as in, how your files are organized) is largely independent of how your code is actually deployed and where it runs. If you are aware that some business logic might one day run in the frontend on the client device, and 4 years later might make more sense ot run in a lambda, that's something you can architect for.

Serverless / stateless is ultimately "functional programming". If you write your code as a side-effect free function, leveraging technologies like WASM, you can keep the same code, and deploy it frontend or backend or both or as a lambda or as a single node worker, and the code itself won't change. These are the things that next.js and vercel and edge computation leverage, but it is true in every codebase (embedded, desktop applications, etc...).

With the crucial difference that "serverless" is proprietary and uses different APIs, so you can't just go to whatever hosting company you want.

Of course, vendor lock-in is a feature because once developers leave a company, someone else with the necessary proprietary knowledge needs to replace you. Spread proprietary cloud stuff like the plague and you'll always be employable somewhere!

use CGI; use strict;

It's often misunderstood that a lot of the much-vaunted cheap hosting providers offer PHP only as a CGI. You would typically pay extra for mod_php.

Python and Ruby have more startup overhead than Perl and PHP, so usually you don't want to pay that cost for every request.

Edit: Not sure why this is controversial. Here is a "hello world" benchmark I just ran on my machine, in units of hello worlds per second: Perl – 1020 runs/second; Python – 78 runs/second; Ruby – 30 runs/second.

Can we have the "soft reload" model like how Django works in development mode?

Drop a file on a server, it notices filesystem change, reloads an app (or spawns a second copy of app, waits for it to initialize, kills original app and switches over to a new one)?

Gunicorn has an option for this[1] so you could enable it on your production server, although I don't think that's recommended.

One problem with this approach is what happens when you're updating multiple files. If the server restarts immediately on the first change, you end up loading a mix of old and new files, which probably won't work properly. But if you delay the restart to wait for all the files, how long do you wait? If the delay is too long it's confusing and annoying (did the server restart yet?) and if it's too short you get mixed versions as before.

So it's better to explicitly signal when it's time to restart. You can still have automatic restarts in the development environment.

[1] https://docs.gunicorn.org/en/stable/settings.html#reload

Assuming you get a new "event" every time a file in the watched folder changes, you could restart the count.

Ex. First even triggers a 5 seconds wait. If before those 5 seconds have passed there is another trigger (say after 1 second) another 5 seconds wait starts, for a total of 6 seconds in this example.

I really like the vercel and co approach to the dev cycle. It's as easy as (if not easier) PHP and you get a huge boost of monitoring / infra tools for a minor cost. I think we are seeing a lot of the "yeet and get shit done" approach with vercel and netlify that we used to with PHP.

Python has had cgi forever: https://docs.python.org/3/library/cgi.html

I would say security by default is a good reason to not have this. I've been burned too many times on PHP projects because someone miss-configured an httpd conf file.

From all the potential web security issues someone can have that one is probably the easiest and most likely you will get right.

The whole reason for the principle, "Secure by default" is because someone is going to fuck up.

Shared Nothing Architecture.