6 ms·

PHP's value proposition has always been one thing - ease of deployment. Seriously, all you need is one install command, one command to start the services, one t

PHP's value proposition has always been one thing - ease of deployment. Seriously, all you need is one install command, one command to start the services, one to git clone the files and one for certbot. And you have a fully functional deployment ready in a single script that can be deployed at scale. No other language can even come close.

aganame 7y ago
These PHP praises frankly sound like trolling. No other language can even come close? You must be kidding. I mean I get it. It's obviously a counter-reaction to all the PHP hate that has been with every PHP thread for 2 decades, and much of it has been unfair, especially for the last 5 or so years. But please let's not swing the pendulum all the way to the other side.
- ollyculverhouse 7y ago
  So given a web server, what language can 'come close' to the ease of deploying with PHP?
  - mgbmtl 7y ago
    I'm a mostly PHP dev, but with apps in other languages, all you need more is a systemd unit file to start the app? (ruby, nodejs, go, etc)
  - hombre_fatal 7y ago
    Unless your only experience is 1999 style FTP with shared hosting and you've never used anything else, I don't know how you can claim that `node server.js` or running your Cargo-built server.exe is somehow harder or more complicated. For example, PHP is complicated enough that people use WAMP/MAMP.exe just for local development.
  - eyelidlessness 7y ago
    "Given a web server" seems a pretty big caveat. I'm not a big node cheerleader (even though I work in it day to day), but it doesn't need to be given a web server to achieve the rest of this claim.
mpartel 7y ago
In the past I sort-of agreed and even chose PHP in a few instances when the project was tiny enough that ease of deployment was a major factor. Nowadays with something like Heroku or App Engine, language has almost no impact on ease of deployment, and even custom deployments are pretty easy once you've practiced the docker/systemd script + apache/nginx proxy dance once or twice.
- eyelidlessness 7y ago
  If we're giving PHP credit here, I think we can say with some confidence that the ease of spinning up a shared server with PHP and MySQL inspired the kinds of super simple infrastructure products like Heroku that are now commonplace. The notion that PHP is easier to deploy used to be true, it's not something that should be dismissed, it's even a pretty big deal. It's a walk up experience that inspired an improved DX for every other mainstream environment. But they've caught up and that's worth acknowledging too.
tuesdayrain 7y ago
All of that can easily be done in Node by setting up the appropriate scripts in the "scripts" section of the package.json file.
sfkdjf9j3j 7y ago
You would also need a properly configured Apache server wouldn't you? I can see the ease of deployment argument in the context of old-school shared hosting providers, but nowadays how is starting a PHP application any harder than Rails or Django for example. And for modern development environments, deployment complexity usually comes from managing virtualized hardware and CI/CD pipelines, which is independent of whatever language your app is written in.
clon 7y ago
> PHP's value proposition has always been one thing - ease of deployment. I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though. Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic That could be Go, could be Rust. But not PHP. PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no. It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290 https://github.com/laravel/valet/issues/290 Turns out if you php-fpm app one Tuesday at 15:43 starts to write more than 4k to stderr (maybe it writes some nice verbose logs after being hit by some recoverable error), you will find yourself wondering what does "upstream sent too big header while reading response header from upstream" imply while your endpoint responds with 502. This is just one possible footgun .. ekhm .. tuning option.

aganame 7y ago

These PHP praises frankly sound like trolling. No other language can even come close? You must be kidding. I mean I get it. It's obviously a counter-reaction to all the PHP hate that has been with every PHP thread for 2 decades, and much of it has been unfair, especially for the last 5 or so years. But please let's not swing the pendulum all the way to the other side.

ollyculverhouse 7y ago
So given a web server, what language can 'come close' to the ease of deploying with PHP?
- mgbmtl 7y ago
  I'm a mostly PHP dev, but with apps in other languages, all you need more is a systemd unit file to start the app? (ruby, nodejs, go, etc)
- hombre_fatal 7y ago
  Unless your only experience is 1999 style FTP with shared hosting and you've never used anything else, I don't know how you can claim that `node server.js` or running your Cargo-built server.exe is somehow harder or more complicated. For example, PHP is complicated enough that people use WAMP/MAMP.exe just for local development.
- eyelidlessness 7y ago
  "Given a web server" seems a pretty big caveat. I'm not a big node cheerleader (even though I work in it day to day), but it doesn't need to be given a web server to achieve the rest of this claim.

mpartel 7y ago

In the past I sort-of agreed and even chose PHP in a few instances when the project was tiny enough that ease of deployment was a major factor. Nowadays with something like Heroku or App Engine, language has almost no impact on ease of deployment, and even custom deployments are pretty easy once you've practiced the docker/systemd script + apache/nginx proxy dance once or twice.

eyelidlessness 7y ago
If we're giving PHP credit here, I think we can say with some confidence that the ease of spinning up a shared server with PHP and MySQL inspired the kinds of super simple infrastructure products like Heroku that are now commonplace. The notion that PHP is easier to deploy used to be true, it's not something that should be dismissed, it's even a pretty big deal. It's a walk up experience that inspired an improved DX for every other mainstream environment. But they've caught up and that's worth acknowledging too.

tuesdayrain 7y ago

All of that can easily be done in Node by setting up the appropriate scripts in the "scripts" section of the package.json file.

sfkdjf9j3j 7y ago

You would also need a properly configured Apache server wouldn't you? I can see the ease of deployment argument in the context of old-school shared hosting providers, but nowadays how is starting a PHP application any harder than Rails or Django for example. And for modern development environments, deployment complexity usually comes from managing virtualized hardware and CI/CD pipelines, which is independent of whatever language your app is written in.

clon 7y ago

> PHP's value proposition has always been one thing - ease of deployment. I think that advantage may have been real at one time, when FTP deploys were a thing. The myth loves on. Folks that chant this praise are often not be the same folks that have to maintain the webserver side of things, though. Easy to deploy looks like this: ./foobar --port=80 > Listening on port 80, ready for traffic That could be Go, could be Rust. But not PHP. PHP webserver / application separation does bring some advantages - for example if you bring your application to a corrupted state or crash it, it will go and die. Recovery is, well "implied". But deployment wise, no. It actually seems to be a LOT harder to run PHP that at first blush. Take this example: https://github.com/laravel/valet/issues/290 https://github.com/laravel/valet/issues/290 Turns out if you php-fpm app one Tuesday at 15:43 starts to write more than 4k to stderr (maybe it writes some nice verbose logs after being hit by some recoverable error), you will find yourself wondering what does "upstream sent too big header while reading response header from upstream" imply while your endpoint responds with 502. This is just one possible footgun .. ekhm .. tuning option.