The drop index.php into a folder is the only way I use PHP now.

Back when I was building applications in PHP it was all frameworks. package managers, op code caching, etc. But I no longer do PHP development but for my own personal websites I still use PHP but in that most minimal form.

Exactly, if one is not developing PHP for the enterprise (maybe some non-enterprise simple projects still use opcodes though? lol), it's silly not to leverage index.php for all it's worth :-)

So where is the hyper-simple JS equivalent for that class of non-enterprise projects, is what I wonder...the enterprise stuff has always been heavy and loads projects down with maintenance debt.

There are projects between hobby users and Facebook, believe it or not :-)

I actually like using a reliable package manager, a wide ecosystem of good packages, and modern language features. There is nothing "heavy" about modern PHP, unless you want it to.

The equivalent for JS is just an HTML file.

> Only nobody uses php that way since decades.

… in your echo chamber. I know first hand of multiple very large corps doing that (one of them being a bank and this is their payment api) and very many smaller shops. Sure, we recommend against it, but saying it’s decades ago like that is nonsense; many people do this because it’s convenient.

What I like about PHP is that it's not just batteries-included, it's "Entire Batteries Plus Store Included". The standard library is huge, documented, and also features 15 years of accumulated notes and discussion right on php.net.

The tendency to have a npm package for everything is overwhelming because you end up with choice paralysis and risk on picking "Oh, you picked CSV-to-array library #823, it's the buggy/insecure/unmaintained one."

File reading excluded, CSV to array is like two generator functions and a main, even with rudimentary schema support. No reason to add a dependency at all.

> Modern php code uses Frameworks, Package mangers, opcode caching, and application servers.

How do these change the way you can deploy PHP files by simply uploading them?

For frameworks, all you do is run a single command to install.

If you mean JS package managers, that's agnostic to what language you use.

Opcode caching doesn't require anything special from deployment point of view and I don't see a need for app server for PHP.

It changes deployment because you need to flush the opcache after deploying new code, for example; you need to install composer packages, restart the app server (if you use one), etc. I mean obviously you still upload files, but there are more steps involved in a proper deployment.

Once you start getting into zero-downtime deployments, you'll quickly see the need for both application servers like Swoole or RoadRunner, as well as strategies that don't leave requests in the air with half the code from the old version and the other half with the new one.

Let HackerNews hobby programmers snark all they want, those are very real problems with very real solutions.

I mean... using a symlink to the deployment root gives a quick atomic swap. You update the link, then reload the server config, no downtime and no partial deployments during a request. This also solves for the opcache freshness as well if I recall correctly. (It's been a little bit since I've done any PHP work)

Of course, you can do that. It’s the strategy Etsy used, for example. Point still standing, that makes deployments definitely more complex than just „uploading a file“.

And then again, you’ll end up wondering why your servers should waste cycles upon cycles for executing the same bootstrap code over and over again, if they could instead only do that once, keep the app in memory, and only execute the request handling code… and just like that, you’ll end up with Octane, or Swoole, or what-have-you.

Exactly! Those languages are working on their own cruft!