Hacker News Reader

Comment by the_trapper | Hacker News Reader

I think PHP endures because it does one thing and does it exceptionally well. There is no other tool that makes the creation of simple dynamic server side web sites as easy and accessible. Simple FTP/SCP deployment to the server is such a killer feature.

It is also one of the few choices available on cheap shared hosting sites.

View on HN

The other thing it does excellently is that you can take any .html file, renamed it to .php and add some <?php code ?> and it'll work.

In a previous site of mine i had the entire site be statically generated but needed some server-side stuff in one of the pages, so i put something like %%PHPCODEHERE%% and modified the script that built the site to replace the %%PHPCODEHERE%% with the contents of a .php script.

Exactly this. I've been doing back-end development for work the last 7 years, first Java then NodeJs and I'm now playing with the Rust web backend (still very early-stage but promised to a bright future IMHO) but my personal blog is still PHP, and so was my wedding's website. Being able to drop a file through FTP on a 2€/month shared server is so convenient!

PHP is the VBA of the web: it's ugly but too useful to ignore.

PHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.

That's not a PHP thing, it's a CGI thing. You can use any scripting language to do it. Perl was popular but you could use Python or even bash.

How is syncing your PHP code with the server serverless?

and now you see why "serverless" is misleading.

"serverless" now means you don't run your own web server, you use someone else's.

That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes onto a webserver when it's needed, and not before.

PHP hosters have been doing this for 20 years. You have 100s of customers on a single machine, running with a single Apache/PHP process (and child forks), and only if that Host+URL of a customer is requested that PHP code actually gets executed, then completely discarded from memory after its finished.

PHP is very much comparable to serverless. All that talk about bootstrapping costs in serverless is something PHP developers have been tackling forever.

This is a very silly equivalence--you're just glorifying vhosts and method dispatch.

The mechanism isn't the point (and vhosts aren't really either). The point is what a developer (or ops) has to think about when deploying, and in this regard, the default PHP model has a lot in common with serverless.

I don't see a difference there, PHP code can run on any webserver your hoster operaters provided they route the request correctly (I've once used a web provider that would rsync your PHP code to a geolocated DC if they detected more traffic from your region). If this is via vhosts or other routing methods is almost irrelevant, PHP code behaves extremely similar to "serverless" code (except it's often much cheaper).

Which is what the earlier poster was alluding too. PHP code is stateless and sits there not taking up any resources until it is needed.

serverless and compute-on-edge are different things.

You still have to deploy to Lambdas.

I believe the post you're responding to was alluding to the degree to which a lot of single-file PHP/HTML is written in a very "serverless-esque" way: no dependencies on an outer framework, and likely scales quite far compared to other languages when run on any number of servers (with the required libraries).

In addition to what you mentioned, with PHP there's no need to start, restart, monitor, or otherwise manage your own daemon. Apache and/or PHP-FPM does that for you.

Reply on news.ycombinator.com