Hacker News new | ask | show | jobs
by greggman7 527 days ago
What would replace it?

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.

6 comments

That's probably the best explanation. There is no real alternative to PHP if you want to host cheap and simple. It's also really easy to deploy WordPress to a shared hoster, just by uploading a few files via FTP/etc and setting up a MySQL connection.

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

> 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. Much of the primitive stuff it started with, has been replaced (I think, rather clumsily, but it works).

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 DB/User, 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, once it's set up. 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 just don't want to have to do that. The moment I walk away from WP, I am sealing my own fate. It will make it ten times as hard to push the sites over to someone else to manage.

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.

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

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

Sorry ;)

What's the issue with CGI ?
CGI is fine, but it’s a rather awkward API, and about the worst way to publish a Web site.

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.

Yeah, I roughly got that, but in which specific way is it bad ?
It looks like you are wanting to argue on some specifics. I probably won't be able to give you what you are looking for.

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.

These days everything that would've been CGI is now FastCGI (even PHP). Or in other words, run one server whose only job is to reverse-proxy requests to another server over a slightly different protocol.

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

When Wordpress first came up, PHP was something anyone with $5 could administer, and Python/Ruby required a lot more money and expertise that put them outside the reach of junior hobbyists.

This was before the days of PaaS solutions like AppEngine.

I don't know any PaaS solution that is not at least a magnitude more complex than a simple PHP shared hoster.

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

https://wagtail.org/who-uses-wagtail/ lists a few companies who would care about low resource use due to the sheer amount of traffic they see.
This. If Symfony or Ruby on Rails or Django or Quarkus or NextJS could replace Wordpress, then they would. I myself wrote Symphony for many years (2008 to 2014) and I was certain it could kill Wordpress, but it failed.

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.

> [PHP] makes sharing a server trivial

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

Riddle me this: if my web page is for a local cafe and I've uploaded 5 images and 7 paragraphs is there anything I shouldn't share?

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.

Many graphic designers don't know how to work with the template systems of CMSs that attempt to serve multiple websites from a single app instance. Wordpress is kept alive, in part, by designers who feel it is easier to hack than any other system.
Because containers don't really solve any problems in this use case (or many others, honestly) and instead make everything more difficult.
That's just CGI. You could theoretically do the same with any other language, but PHP is just the most popular.
PHP integrates with the server. It does not have the spawn a new process per request like CGI
I think dreamhost runs php as fcgi.

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.

I don't understand the distinction you're trying to make.
Not having to spawn a new process greatly decreases the time it takes to process a request, which greatly increases the amount of requests you can serve with a given amount of hardware.
The difference in resource consumption is huge.
What is it about PHP that makes this low-resource scenario possible?
I would say the biggest reason might be that PHP doesn't have to worry about the web server aspect. Apache (or another webserver) serves the requests, PHP just returns the page to Apache. This is one of the ways that Apache can serve hundreds of PHP based sites, cause there's no need to spin up another web server and Apache is pretty fast at what it does.
PHP being low-resource is a fallacy. You either:

- 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).