PHP is the right tool for the job (for all the wrong reasons)

One thing I really like about PHP is it's execution model. Here, every request is mapped to a single static .php file which is executed by a single PHP interpreter process. The execution is essentially stateless (aside from any bugs in the interpreter which from what I've seen tend to be few when it comes to this issue). Essentially, every request gets its own execution environment and does not have to worry about anything outside of itself. You also get code reloading: requests currently in progress are handled by old code. New requests are handled by new code after you replace the .php file.<p>Contrast this with RoR/Django/nodejs/etc. Here you have to be the one controlling the process/thread. You can mess up and create a dirty execution environment. In your requests you have to be aware of what the other requests might be doing at the same time. Moreover, running two simultaneous applications requires two different execution environments (apache processes, nodejs processes, etc.) The common solution to this is to either provide some environment isolation by running one set of interpreters per application or to have a whole virtual server dedicated to every application, incurring the overhead of an OS per app.<p>Don't get me wrong, I detest writing code in PHP for many reasons, but the execution model is efficient: if you want more power for your applications, just increase the number of available interpreters. Moreover, every interpreter is the same, so by doubling your total number of available interpreters, you double the concurrency of all of your applications. This is the pinnacle of cloud apps: you have a simple single toggle that controls how many requests you can process concurrently. This is why shared hosting now costs $2/month while Heroku is an order of magnitude more expensive.

These threads always get "interesting" don't they?<p>A common problem I see in these kinds of discussions is engineers. Yup, you and me. In my case it took me years to move away from being a typical clueless egocentric engineer. I am sure I still am to some extent. Whatever is left pales in comparison to my younger self.<p>What made the change? Business. And the realities of the insanely simple business equation coupled with actually launching and running them with my own money.<p>There's a huge difference between holding a cat by the tail and watching someone else do it from afar. Huge.<p>Where I am going with this is that we (engineers and technical folk) tend to focus on, and talk about, FEATURES almost at the expense of BENEFITS. The reality of business is that the value of the former pales in comparison with that of the latter.<p>I love Python. However, when faced with having to do a benefits analysis it is almost impossible to not choose PHP these days. Liking it has nothing to do with making the choice. Well, it shouldn't.<p>I wish engineers could see what they sound like from the vantage point of a business person. You see this all the time at pitch events. There's an absolutely abysmal difference between presentations from "virgin" engineers and those who have had even a few business scars.

Can you spot the outliers here?: "where PHP has excelled with projects like Wordpress, Joomla!, <i>Drupal</i>, <i>Magento</i>, Moodle, PHPBB, and so many more.".<p>Some projects "swing the PHP-way" and they are "retarded" but easy to use and fix and keep with the "fail fast, fail cheap" philosophy. Otoh, things like Drupal or Magento "swim against the tide", are hypocritically claiming to be newbie/weekend-warrior friendly, and basing your project on them lands you over-time and over-budget 90% of the time, ending up costing more than a custom made Rails app - unless you have the rare mystical creatures called "real Drupal (or Magento) gurus" working for you. It's a very weird jungle the PHP ecosystem nowadays, and lots of the creatures in it <i>byte hard!</i>. If you stick to riding a gentle sloth like WordPress, you're fine... but I'd suggest rapidly switching languages and technologies (something like Django + django-cms is almost as cheap and can be deployed even on dirt-cheap shared hosts) as soon as you grow over WordPress level, otherwise something will end up biting you hard!

I don't understand why "low-skilled people can use it" is constantly trumpeted as an upside. If you can't work out how to set up the DB by hand (for example), there's little chance you're going to be able to get through the rest of the job without making a horrible mess which you (more likely your client) will come to regret.<p>Imagine if we took this attitude in civil engineering, or medical science. Not good. Obviously not every web project is as important as those two things, but "the barrier to entry for foot-shooting is low!" should never be a plus point for a technology. Especially when it's not your foot.<p>There's obviously a need for a tool for low(er) skilled people to make websites, but perhaps it should be less powerful to match? It should at least have abstractions that don't leak so much.<p>I'm happy to be lectured to about why this is wrong.

Why is PHP so threatening to so many developers? Don't use it. Don't take jobs where it's the primary tool.<p>The complaining that it's a poor tool while many people create tons of value with it leads me to believe there's a disconnect between the two camps that I don't get.

I don't see PHP as any more easily deployable than Node, Rails or even self-contained Go/Gorilla.<p>Python, maybe, but even that's trivial to get going. Most of these - save Go - are installed on shared servers anyway.<p>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."<p>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.<p>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.

If you use a decent web framework for your project, I think PHP isn't a terrible solution. It will be maintainable, organized, thoughtful, and documented. Obviously in the end, <i>it's still PHP</i>, but a good framework makes those more complex PHP applications understandable.<p>If you're building a website (in any language) without a framework, you're doing it wrong...

I'd love to use Python or Go or whatever. But everyone wants to pay me to code PHP on some mediocre stack. So be it ...<p>At least I home I am free to use whatever I want. So I use Symphony2 ;) ... which adds verbosity and complexity to a language that still can't decide if 0 is something empty or just the number 0.

This is what the team behind Discourse is attempting to address somewhat, making Ruby software as idiot-proof to set up as PHP applications.<p>Whether they will end up succeeding is yet to be seen, but this does definitely seem like an area where competition will benefit the greater good, as displacing PHP with any one of the better designed languages out there would benefit the internet as a whole.<p>I do wonder though: is the procedural nature of PHP equally responsible for it's adoption by inexperienced developers?<p>Sure, PHP is cheap and widely available, but you also don't need to understand the concepts behind object orientation to hack together a "dynamic" website with a few includes. And at that point you're just familiar enough with PHP to favor it for future development.

My opinion on the success of PHP has more to do with how it integrates with Apache... All of the other languages were designed as languages first, then web development was bolted on... HTTP is fundamentally request / response oriented and PHP provides brain dead access to GET and POST vars via simple to understand global variables... In addition, the same mechanism is provided for session state...

I would note that the article doesn't consider having to install any custom PEAR/PECL packages that your PHP application might require. Sometimes they need to be installed on the command line (as root), or sometimes as OS packages. If you're using managed web hosting, you will probably need to email the administrators and ask them to install the needed packages, and they might refuse.<p>In this context Ruby on Rails wins because of its standardized Gemfile approach. Every RoR application always specifies the dependencies in a standard way and their installation is always part of the deployment process. PHP has nothing like this.<p>The same applies to asset pipelines. When your application contains SASS/SCSS or CoffeeScript files, you need to worry about how they're going to be compiled, optimized and deployed. Ruby on Rails also standardizes this so that all you need is the same basic RoR application layout that you generated in the beginning.<p>So, as long as the web hosting provider supports Ruby on Rails, I think it's currently the simplest way to deploy full-featured web applications. Using PHP will require you to either 1) not use many modern web technologies or 2) build your own deployment processes to support them.

"the only language that makes deploying a website effectively idiot-proof"<p>I work for a large web host and can assure you this is not the case.

Exactly. I detest PHP, but I've used it to quickly build a sign-up website for an event. If you pair PHP with an interface library like Bootstrap and an ORM like Paris/Idiorm you can have something up and running cheaply and quickly. Is it maintainable? No, but that's not important in this case.<p>edit: let me clarify, I don't assert that ALL php code is unmaintainable, just the quick site I built. Though if you're in the mood to argue: statically typed languages are infinitely more maintainable than dynamically typed ones in my opinion.

Simply not true.<p>Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.<p>The article is talking about managed hosting, were that might still be true (Admins are incredibly conservative and stubborn individuals).<p>But for everything else? PHP doesn't work 'out of the box'. It's due to the work of a poor admin somewhere that you can just upload your crap and it runs.<p>In contrast, I can install and setup a complete Ruby server in about 15 minutes.

The one technology that's nearly as ubiquitous on shared hosts as PHP is CGI. Plain, one-shot process-per-request CGI.<p>So if we want a language that can displace PHP in its niche, perhaps we should choose a language that's amenable to short-lived CGI processes. For this, I think a language that can be compiled ahead-of-time to fast-starting native code is appropriate. By fast-starting, I mean that startup should consist of little more than the kernel's exec routine.<p>I think the Go language would be a good fit.<p>So the next time you need to write a web app that should be easy to deploy on a shared host, try writing it in Go, using a web framework that supports FastCGI, which can then degrade to plain CGI. Then compile the app on a Linux box, upload it to the shared host, and thanks to the self-contained nature of executables produced by the Go toolchain, the app should be ready to go with no fuss.

When people complain about McDonalds being horrible food, not fit for human consumption, they will often talk about the health benefits of their favorite foods. And you know what? They're right.<p>But McDonald's is still better food.<p>Imagine a programmer from a top software company writing long-winded rants about how horrible PHP is; how PHP should cease to exist. Everyone would roll their eyes, and say "Well that's the bloody point of PHP, you idiot!"<p>McDonald's caters to poor people, especially those who don't have their own cooking skills. This is the challenge for all the people who want to complain about McDonalds - if your chosen food is so much better, then make it accessible in the way that McDonald's is.<p>--<p>"The easy path is often not the best path." -Me

I guess that if "can be deployed my a non-technical user through FTP" weighs heavier than all other technical considerations put together, then I guess PHP is the right choice. Or you could just CGI.

Try dropping files in an environment where apache / php is not installed, or where db drivers or gd bindings are missing. Or try to set it up with nginx and php5-fpm.<p>There is a big difference in being ubiquitious and being easy to use, and lets not infer casuality where there is none. Most popular PHP projects come with a good installer, but go to sourceforge and try a lesser known project. Or go back to the 90s and see if installing drupal or wordpress was as easy.<p>I can argue that shell scripting is the best programming language by this logic.

I disagree. Deploying a Python site, for example, is equally easy.

Its sad no other languages have noticed this. PHP is a natural progression from HTML for beginners. Learn HTML, sprinkle a bit of inline PHP here and there, and bam you have a "dynamic" website.<p>An incredibly bad and impossible to maintain website, but a "dynamic" website none the less.<p>From there, ramping learning up to MVC / Frameworks / caching / templates / optimizers is all small leaps from the initial understanding of "put html here, sprinkle php here". Nothing else really has this apart from maybe ASP.

&#62; It works, out of the box, for people who don't know what they're doing<p>here's the worst of all the bad reasons right here..

How cheap does the shared hosting need to be? DigitalOcean offers virtual machines starting at $5/month. At a somewhat higher level of abstraction, WebFaction offers shared hosting for $9.50/month with a broad selection of technology stacks.

Only way to "idiot proof" anything is to not let idiots build your software. Regardless of the tools, idiots <i>will</i> create a mess.