5 ms·

One of the key reasons why PHP remains so widespread in use is the ease of deployment. No other language can match it. PHP is the only language with almost uni

One of the key reasons why PHP remains so widespread in use is the ease of deployment. No other language can match it. PHP is the only language with almost universal support among web hosts. It can run on basic shared hosting plans and on nearly every server. It can be deployed by simply uploading your code to a directory on your web host. Sure, it's a widely criticised language (even within the PHP community), but it still accounts for the vast majority of server side code (80% according to some sources). What's baffling is why other languages and so many developers are blind to this problem of easy server install. They think it's a non-issue. Prolific blogger and programmer, Jeff Attwood ranted about how he disliked PHP in one of his blog posts, but recognised that: "If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option." To broaden choice, Attwood argues we should: "build compelling alternatives and make sure these alternatives are equally pervasive, as easy to set up and use as possible." That was written in 2012. (https://blog.codinghorror.com/the-php-singularity/ https://blog.codinghorror.com/the-php-singularity/). It's 2017 and what's changed? Nothing. Having a ridiculously easy web app installation process for servers would unlock countless opportunities for developers to reach more users or customers. And it has, for many PHP open source projects and products. Want your customers to self-install your software? Good luck getting them to do that easily with any language other than PHP.

aaron-lebo 9y ago
It's a good barrier to entry. If in 2017 you can't figure out how to setup an ec2 instance and run a simple webserver in any language, then you don't need to be setting up software. It's not hard.
- jimktrains2 9y ago
  Not even that, but with services like heroku and app engine, upload-and-refresh style development isn't php or old asp or cgi on a shared host anymore.
- wolco 9y ago
  But people do need to setup software and run their business. If your favourite language can't abstract away those setup details your language will be skipped by the masses who want to get things done and won't want to invest the time in the setup details. It was easy to get setup and start programming in the 80s. That allowed you to spend time/energy on the complex logic you needed to write the program. Most programming is so much easier the level of math required is so much smaller and most websites are simple crud. Why are we making the setup process more difficult? Do we really need a gate keeper?
- kalleboo 9y ago
  You can keep saying that but then people will keep using PHP
mratzloff 9y ago
Sure, that was true-ish a decade ago. It's not anymore, and hasn't been for awhile. Here's one example: https://www.phusionpassenger.com/ https://www.phusionpassenger.com/
- te_chris 9y ago
  Not quite. Passenger makes Rails deployment easier, sure, but it's the fundamental nature of PHP not requiring an app server and just loading everything per request that's the real trick - I know FPM changes that, btw.
  - mratzloff 9y ago
    That's a fair point. "Why didn't it change? I updated the code." That's definitely a barrier when there's no distinction between development and production.
skrebbel 9y ago
It's 2017 and what's changed? Nothing. This is not true. We got AWS Lambda and friends, which let you write PHP in any language.
k__ 9y ago
Doesn't PHP require a webserver to run? Solutions based on Node.js can be stand-alone.
- Felk 9y ago
  Yes, but you should proxy your Node.js application behind a production ready webserver like nginx or Apache anyway.
  - tannhaeuser 9y ago
    Why?
    - jszymborski 9y ago
      Because your nodejs server will get DDOS'd when 10 people access it simultaneously. (Hyperbole that hopefully illustrates my point)
      - tannhaeuser 9y ago
        No it won't, unless you're doing something stupid in your app, such as using synchronous or CPU-heavy code. But putting nginx in front of it doesn't save you here either; you'd need a caching reverse proxy instead. The only thing where nginx might help performance-wise here is static file access (of eg. static web assets such as CSS or static HTML).
      - k__ 9y ago
        Hm, I use Nginx mostly for routing and static files and not for performance reasons.
- moqster 9y ago
  php -S script.php
mjw1007 9y ago
The language developers were never really in a position to fix this problem. After all, in 2002 (the date of that Q&A), you could already deploy Perl or Python scripts by "simply uploading code to a directory", if mod_perl or mod_python was installed by the hosting provider. Coordination problems are difficult.
jaequery 9y ago
i agree the ease od deployment was key and it still is to large degree but it along brought a huge problem with it, security. you have to realize php is also incredibly insecure as well. chmod 777 on install instructions? on a shared webhost server? this really was and maybe still is the "thing". the nature of being able to upload a php file to server on the public docroot makes the language always prone to hacks. sure there have been improvements with things like mod_suexec and fpms but this now makes things that usedto be easy now hard, ie htaccess and rewrite rules.
tsuraan 9y ago
How is a PHP "program" easier to distribute and run than one written in Go, Rust, or Haskell? For any of those three, you have a self-contained executable that you run. One scp to your server, one service restart, and you're running your new server. How could any distribution and deployment process be easier than that?
CM30 9y ago
This in turn also helped software like WordPress and phpBB become significantly more popular than their alternatives. They may not have been better coded, nor more secure or feature rich, but setup was a complete walk in the park. At most, you needed to set up a database through CPanel or whatever you used, then upload some files and run an installer. At least, you just clicked a few buttons in the control panel to install the system there and then. Meanwhile, recent attempts at fancier competitors (like Ghost and Discourse) have completely failed to capture the marketshare of their PHP based counterparts because they're just more difficult to set up for the non technical individual or company. Their creators put image (aka a more 'glamorous') tech stack above ease of use, and paid the price. PHP's ease of deployment is basically why so many of the larger CMS systems of today got popular at all.
strictfp 9y ago
It runs everywhere because it's really old and popular. So you could just call it momentum. I for one would never choose technology based on momentum alone. And you might get PHP running in almost all servers, but that says nothing about all your dependencies such as mail servers, message queues and the like. So the fact that it runs everywhere doesn't actually mean that much.

aaron-lebo 9y ago

It's a good barrier to entry. If in 2017 you can't figure out how to setup an ec2 instance and run a simple webserver in any language, then you don't need to be setting up software. It's not hard.

jimktrains2 9y ago
Not even that, but with services like heroku and app engine, upload-and-refresh style development isn't php or old asp or cgi on a shared host anymore.
wolco 9y ago
But people do need to setup software and run their business. If your favourite language can't abstract away those setup details your language will be skipped by the masses who want to get things done and won't want to invest the time in the setup details. It was easy to get setup and start programming in the 80s. That allowed you to spend time/energy on the complex logic you needed to write the program. Most programming is so much easier the level of math required is so much smaller and most websites are simple crud. Why are we making the setup process more difficult? Do we really need a gate keeper?
kalleboo 9y ago
You can keep saying that but then people will keep using PHP

mratzloff 9y ago

Sure, that was true-ish a decade ago. It's not anymore, and hasn't been for awhile. Here's one example: https://www.phusionpassenger.com/ https://www.phusionpassenger.com/

te_chris 9y ago
Not quite. Passenger makes Rails deployment easier, sure, but it's the fundamental nature of PHP not requiring an app server and just loading everything per request that's the real trick - I know FPM changes that, btw.
- mratzloff 9y ago
  That's a fair point. "Why didn't it change? I updated the code." That's definitely a barrier when there's no distinction between development and production.

skrebbel 9y ago

It's 2017 and what's changed? Nothing. This is not true. We got AWS Lambda and friends, which let you write PHP in any language.

k__ 9y ago

Doesn't PHP require a webserver to run? Solutions based on Node.js can be stand-alone.

Felk 9y ago
Yes, but you should proxy your Node.js application behind a production ready webserver like nginx or Apache anyway.
- tannhaeuser 9y ago
  Why?
  - jszymborski 9y ago
    Because your nodejs server will get DDOS'd when 10 people access it simultaneously. (Hyperbole that hopefully illustrates my point)
    - tannhaeuser 9y ago
      No it won't, unless you're doing something stupid in your app, such as using synchronous or CPU-heavy code. But putting nginx in front of it doesn't save you here either; you'd need a caching reverse proxy instead. The only thing where nginx might help performance-wise here is static file access (of eg. static web assets such as CSS or static HTML).
    - k__ 9y ago
      Hm, I use Nginx mostly for routing and static files and not for performance reasons.
moqster 9y ago
php -S script.php

mjw1007 9y ago

The language developers were never really in a position to fix this problem. After all, in 2002 (the date of that Q&A), you could already deploy Perl or Python scripts by "simply uploading code to a directory", if mod_perl or mod_python was installed by the hosting provider. Coordination problems are difficult.

jaequery 9y ago

i agree the ease od deployment was key and it still is to large degree but it along brought a huge problem with it, security. you have to realize php is also incredibly insecure as well. chmod 777 on install instructions? on a shared webhost server? this really was and maybe still is the "thing". the nature of being able to upload a php file to server on the public docroot makes the language always prone to hacks. sure there have been improvements with things like mod_suexec and fpms but this now makes things that usedto be easy now hard, ie htaccess and rewrite rules.

tsuraan 9y ago

How is a PHP "program" easier to distribute and run than one written in Go, Rust, or Haskell? For any of those three, you have a self-contained executable that you run. One scp to your server, one service restart, and you're running your new server. How could any distribution and deployment process be easier than that?

CM30 9y ago

This in turn also helped software like WordPress and phpBB become significantly more popular than their alternatives. They may not have been better coded, nor more secure or feature rich, but setup was a complete walk in the park. At most, you needed to set up a database through CPanel or whatever you used, then upload some files and run an installer. At least, you just clicked a few buttons in the control panel to install the system there and then. Meanwhile, recent attempts at fancier competitors (like Ghost and Discourse) have completely failed to capture the marketshare of their PHP based counterparts because they're just more difficult to set up for the non technical individual or company. Their creators put image (aka a more 'glamorous') tech stack above ease of use, and paid the price. PHP's ease of deployment is basically why so many of the larger CMS systems of today got popular at all.

strictfp 9y ago

It runs everywhere because it's really old and popular. So you could just call it momentum. I for one would never choose technology based on momentum alone. And you might get PHP running in almost all servers, but that says nothing about all your dependencies such as mail servers, message queues and the like. So the fact that it runs everywhere doesn't actually mean that much.