PHP is unique in that it makes sharing a server trivial and low-resource compared to almost every other solution.
A simple example might be that you can run 100s of PHP forums on a single machine low memory machine but if you want to use discourse (not written in PHP), it requires 10x 20x the resources for a single forum.
This is true about almost every other solution AFAICT.
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.
There are countless efforts to make the next Wordpress out there, yet no combination of Scheme and Rust is going to make up for the critical missing ingredient of "right place at the right time".
Ex-Wordpress users are just going to diffuse into all the other decent options that already exist. Or stick with a Wordpress fork that caters to them. Though note that Wordpress isn't going away. How many Wordpress users even know who Mullenweg is?
The idea of cobbling together yet another blog platform that will somehow capture these users better than Wordpress plus all the decent incumbents is some good ol fashioned developer hubris. :P
Right timing absolutely, but there was also great product sense there
Drupal feels like it's a bureaucrats paradise. Other CMSs never got there neither
Processwire OTOH is fantastic in this regard. Super small and generic core with minimal, close to non-existent attack surface, and a programmatic API that lets you solve custom functionality with a few calls to the content API instead of another plugin.
Leads to practically maintenance free sites.
Almost the security of a static site, with the flexibility and dynamic features of a proper cms.
After having the nightmare of maintaining a dozen WP and Drupal sites in the past, I can now just let the sites chug along for years without intervention.
PHP is why WordPress was a success. PHP is available basically everywhere, for cheap. You can get a $5/month hosting plan that'll give you a VPS with mod_php and mysql and you'll be able to install WordPress. (Also, WordPress put some actual effort into having a quick-and-simple setup process. If you can upload some files onto a server, it can take it from there.) Thus anyone can trivially install WordPress.
There's "better" languages, but even today they tend to require more of you to get a working site deployed.
Of course the model is flawed, but so easy to get started with :)
I imagine that a spiritual successor would have a one-click install in many web hosts, which is all but impossible if not still written in PHP, and then installable through the various turnkey web hosting reseller stacks (e.g. Softaculous).
Then, replicating many of the popular plugins, and getting a whole community of contributors onboard who already make their living off WordPress and have little incentive to adopt something with little traction.
WordPress isn't a code framework; it's a very complete application with a massive ecosystem of plugins that serves as its moat.
Plenty of people have made better CMSes, Wordpress is big because it got big, and a lot of people depend on it. And since an enormous number of people are involved with it, your upstart system will never have the capability of Wordpress. Whatever capability you come up with, somebody will have already made a horrible module to install on Wordpress to do it that after 10 years has become almost alright, or at least all of the flaws have been posted on messageboards and everybody knows how to work around them.
Wordpress isn't wordpress because it's good, it's wordpress because it was good enough at the time, and its competition was Drupal and Joomla (or something not PHP.) PHP baggage? PHP isn't PHP because it's good, it's PHP because of mod_php, and cheap hosts. To repeat, your choices: Wordpress, Joomla, Drupal, or figuring out how to run another language on your cheap host, or having to pay to upgrade your hosting account. By far the best option for most people was Wordpress.
If you want to compete with Wordpress, first get a time machine, then go back to that time and write something better in PHP.
I mean no offense OP but it's obvious you have no clue at all about who actually uses WP and why they do it.
And I don't blame them! I run wordpress sites and I sigh with frustration any time I have to insert a custom HTML block, and I am technical. When I'm writing on WP I want it simple and easy.
WP is also not just a CMS where you can drop in something else. It's a colossal ecosystem of plugins, themes, and so on. Some sites run on entire mini-ecosystems within the WP ecosystem, e.g. generatepress/generateblocks/generatecloud.
However, it has recently shifted to more limited audience. (payed subscription-based content with different tiers)
I'm imagining some very pluggable and template driven runtime that you can ship very declarative packages for. The spicy take would be to use a Scheme for the templating around some robust Rust core, but that's probably not the widest appeal. Maybe there would be some clever way to bootstrap it out of PHP so that you can keep using shared PHP hosts and they wouldn't have to bring along a new software distribution.