Or is CGI still a thing and a possible alternative for shared webspaces?

I think I just threw up a little, in my mouth...

I don't think there's a viable alternative to PHP. The nerds here, hate it (and they aren't really wrong). I hate it, but it is undisputed God Emperor of Cheap Hosting. There's nothing that even comes close, for simplicity, speed, robustness, cost, and ubiquity. There are millions of pages of support, years of support forums, and hundreds of thousands of people that can work with PHP at an expert level. Despite the hate, PHP is a mature, modern language, still very much under development, and supported by many corporations.

The simplest hosting solutions have LAMP ("P" being "PHP"), and there are millions of LAMP servers out there. Every single one can run WP, simply by uploading a few files, creating a MySQL instance, tweaking a config, and Björn Stronginthearm's your uncle. Or, with things like WPE, you can click on a button in your control panel dashboard.

Also, non-HN-readers can manage just about every aspect of a WP server. People have made careers from that.

This sucks. I run a couple of sites. I use WP, because it means that I don't have to waste much time, managing them. I could definitely switch over to a static generator (what I would use, if I didn't do WP), or even write my own sites, using handcoded HTML (I have done that, and have even written my own CMSes, in The Dark Ages).

I am an indifferent (at best) Web designer. Almost every person here, could probably code circles around me. That means that working on Web sites is painful and slow, detracting from what I'm actually good at.

This sucks.

>I think I just threw up a little, in my mouth...

Sorry ;)

I mentioned writing CMSes, and one of them was in Perl (using CGI). I still wake screaming, sometimes, and that was probably 25 years ago.

With me, it had to do with the languages I wrote (C and Perl), that required CGI to publish. CGI did fine, but it's fairly primitive. Just another system text pipe (which, TBH, is pretty much what is going on, under a Webserver).

But for most folks, CGI is unapproachable. That's what PHP gives people. It was so easy to use, that anyone that could edit an HTML file, could also write powerful programs in PHP. It was integrated into the Webserver, not the system (as far as the user was concerned).

At the time I first encountered PHP, ColdFusion was an industry standard for that kind of thing, but it was a commercial product, locked to a single vendor. PHP gave hosting companies a fairly simple package (for free) they could compile into their Webserver, that would give their customers that power.

Nerds have no issue, using things like CGI, but most folks aren't nerds, and we sometimes have a real hard time, understanding that. Nerds that do, often become rich.

So I was literally trying to know more. (And I understand a bit better now, thanks.)

I think that anything that will interact with remote browsers, should go through a Webserver. Many utilities actually have their own built-in webservers (not sure that’s always a good thing).

Because the simplicity results in various footguns, just like most programmers probably shouldn't use C these days ?

("Webserver" sounds like an extra layer on top, like how Python allows you to (mostly) forget about memory handling issues ?)

Is it also because simplicity either doesn't add performance here, or is it just because the performance is rarely needed ?

It’s what systems programmers would like, because we don’t like things that get in the way. However, most folks aren’t systems programmers. They want padding and safety nets.

This was before the days of PaaS solutions like AppEngine.

As much as I hate PHP, the typical LAMP shared hosting is by far the most simple kind of PaaS.

It can be used in shared scenarios, but it's nowhere near as automatic as "every file with a particular extension" like PHP...

Is that still a thing? Why would an application on a server share anything other than the kernel?

Wordpress optimized hosts will have "servers" sharing the apache, the kernel, the php libs, even the DB instance. The effective burden of an additional host is tiny. Which is perfect for a local cafe's webpage which might be lucky to get a hit an hour.

Now how do you think you'll compete on price by using containers when your competitor can host a 100x the cafe web pages? The cafe owner does not care that they are sharing a php lib instance. They care that their 7 paragraphs appear when the page loads.

- use mod_php which must start an interpreter instance for each request and has to dump all associated resources (db handle and the like) and memory when the request is served

- use something like FPM that has a pool of workers ready to communicate with the web server, which is more or less what every other languages do, if not via fast-cgi just by proxying an application server

Another way is event-driven, async PHP application server, but again it's not any different than similar solutions in other languages.

Now why people think PHP is low-resource ? That's all rose tinted glasses, because back in the days when everyone just used mod_php on cheap shared hosting for low-traffic websites, the execution model made it possible to get away with leaky apps since all memory was flushed at the end of the request.

If you want to go low-resource, use something like Go which is both much faster than PHP and has a lower memory footprint or choose an execution model that shares resources between requests (available in any JS, Python, Ruby, whatever you like).

I'm actually not sure that fcgi is that bad, even for other languages, but most shared hosts will probably limit what you can do in terms of resources.

The combination of Wordpress's defaults, its ease of use by designers, and the ability for one server to handle hundreds of installments, means that almost nothing can replace it.