I don't see PHP as any more easily deployable than Node, Rails or even self-contained Go/Gorilla.
Python, maybe, but even that's trivial to get going. Most of these - save Go - are installed on shared servers anyway.
What this sounds like to me is "I'm most comfortable with PHP, thus it's faster (read: cheaper) for me to create freelance projects in it."
Which might be true; there is a cost associated with learning and thus becoming comfortable in another language. But that's a very different argument than you're making here, Sam.
If someone asked a freelance programmer to make X and you can make it in PHP, Python or Ruby ... the actual cost of development should be relatively even. What you're factoring in is an inherent time cost for your lack of comfort in the other languages.
Come on, I hate php with a passion and even I will admit it's easier to deploy than anything else. Go comes close, but still requires writing a service.
With Python, you need to create a service to run your WSGI server and proxy it from your web server. You also need to handle your static files properly. PHP, you just copy everything in there.
Hell, I have half a mind to create a project that will run Python scripts CGI/PHP style (run this file and send whatever it returns), just to make deployment easier for people. I'm not convinced the convenience is worth the cost of this horrible dirtiness, though.
The problem comes when deploying PHP to someone elses server.
Since apache and PHP are usually tightly coupled together and PHP has a concept of global configuration that applies across the whole server.
So you have some PHP app that works fine locally but fails in weird ways on deployment because the server was configured using cPanel by someone who didn't know what they were doing and if you change settings you risk breaking whatever other random php scripts are running on the server.
So you end up hacking around with .htaccess files to get things working.
With Django etc you get a to have a "clean room" and run in relative isolation, only interacting with the outside world via proxies.
What PHP is however is cheap to deploy. It's annoying to have to think about and pay for "instances" , "dynos" , "VPS" etc when you just want to put up a webpage with a bit of server side logic.
> Come on, I hate php with a passion and even I will admit it's easier to deploy than anything else
I don't see how this is true anymore. Setting up LAMP versus setting up LAMPython or Node are all one line of aptitude/(your package manager here). I can have a LAMP stack spitting out "hello world" in the same time it takes me to get a Node app running.
Say you're on a shared host. How do you deploy Python in the same time as copying a few files in? You have to copy the files in and do some more things, which is a strict superset of the PHP way to deploy.
Would this be useful to you? It might be a bit problematic to integrate with servers (as you'd need the server to support that sort of hackery), but, from what I recall, mod_python did support exactly this use case.
Not quite; I'm also factoring in support costs (both to me, and the client), as well as the ability to sell a higher-costing hosting solution to the client.
I'm quite comfortable deploying python projects, and I've done it for a number of clients, but the problems I'm faced with are:
- Sometimes the client comes with hosting for a previous site, and insist that it has to be hosted in the same location
- There isn't much in the way of reliable, cheap hosting where the client will get support for anything other than PHP.
- I am not going to manage a client's server for them. They do not pay me enough to justify waking up in the middle of the night to restart a linode that crashed. I am not in the hosting business (I used to be), and I like it this way.
I will often try to push the client towards managed business hosting, where there's a bit more freedom to move, but even then, it's an uphill battle. PHP is a (the) reality of my line of work.
Right, but you're still confused. In these cases, it's not that PHP is a tool for the project, it's that PHP is a part of the project.
Honestly, shared hosting rarely even handles PHP - I don't know many hosting places that will support the code you write. I can't see going to your host and complaining that your site is down because you wrote a script with an infinite loop that's eating up Apache.
They won't support the code; that's not their job. They will restart the server when it goes down, and handle firewalls/security/keep their servers clean of root kits, etc.
Dreamhost, as an example (seeing as I use them), just upgraded all of their servers to support PHP 5.4, which is much better than any of the other hosts I've found. They're cheap, give relatively good support, and have recent versions of PHP available. If there's a problem with PHP or apache, that isn't broken application code, they'll fix it.
So in other words, the application will work just fine the day you sign off assuming the client doesn't update the language core.
Which is no different than with Dreamhost in this scenario. If, for example, PHP 5.X or 6.X ends up breaking your code, it's not like Dreamhost is going to debug it.
There's no functional difference here between PHP and any other language except that the hosting provider will automatically update PHP. And there's no guarantee that won't bork something else (which they will also not support).
No responsible webhost would just roll out a new major version of PHP without warning. Dreamhost have made their servers support it, which means that it is now an option that you can pick, along with PHP 5.2, and 5.3, in multiple modes (cgi, fastcgi, etc.).
But even so, if I build some PHP code that isn't future-proof for even the warranty period that I offer on any code, then I've got to fix it at my cost. If I build some code that, in 3 years time becomes incompatible with a new version of PHP, then it can be fixed then. I can't be expected to predict the future of PHP and build forever-proof code, though.
How often does the language core actually break, though? That's an absolute fringe case.
So what you say is true: they won't support code, but they'll restart the server and handle core updates. That isn't a big enough benefit for someone who detests a language that much.
I still think you're more comfortable with PHP than anything, which is how your valuation is being assembled.
>Seriously though, I don't understand how that is really any more work.
Obtuse on purpose? For one, what npm install? On most shared hosting services there is no Node environment at all. Heck, in most of them you cannot even install one IF you want it. We're not talking VPS here.
If you read the article, our topic is where the vast masses get to deploy: in shared hosting services. No VPSs, no AWS, no Heroku, no nothing.
Python, maybe, but even that's trivial to get going. Most of these - save Go - are installed on shared servers anyway.
What this sounds like to me is "I'm most comfortable with PHP, thus it's faster (read: cheaper) for me to create freelance projects in it."
Which might be true; there is a cost associated with learning and thus becoming comfortable in another language. But that's a very different argument than you're making here, Sam.
If someone asked a freelance programmer to make X and you can make it in PHP, Python or Ruby ... the actual cost of development should be relatively even. What you're factoring in is an inherent time cost for your lack of comfort in the other languages.