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

http://blog.samuellevy.com/post/41-php-is-the-right-tool-for-the-job-for-all-the-wrong-reasons.html

by samuellevy • 13 years ago

87 143 13 years ago

blog.samuellevy.com

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.

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.

jordan_clark• 13 years ago

> Is it maintainable? No

I think that's an exaggeration. Also, I have something to say about JIT.

mgkimsal3• 13 years ago

"Is it maintainable? No"

Anyone who has worked with codebases in multiple languages for any length of time realizes that's a wrong statement. Maintainable is, to some degree, in the eye of the beholder (and often author), but you can write unmaintainable code in any platform. Everyone seems to love RoR - I inherited a Rails 1 app written over 18 months that still didn't work right, and was essentially unupgradeable - every piece of advice from every Ruby person I talked to was "just start over in Rails 2 and port some of the old logic over".

OK - so now I'm talking 'upgradeable' vs 'maintainable'. Try to 'maintain' a Rails 1 app in 2011 - simply searching for how to do certain things in Rails 1 is pretty hard to do, because the docs are wrong/outdated or simply gone.

But hey - "Ruby is maintainable, PHP sucks", right?

Give me a well-thought out Zend Framework app written by a senior developer with experience writing good code vs Rails hacked together by someone with 2 weeks of udemy lessons under their belt any day.

jtreminio• 13 years ago

"I don't assert that ALL php code is unmaintainable, just the quick site I built. "

Sounds like you're the problem here.

bradwestness4• 13 years ago

This is what the team behind Discourse is attempting to address somewhat, making Ruby software as idiot-proof to set up as PHP applications.

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.

I do wonder though: is the procedural nature of PHP equally responsible for it's adoption by inexperienced developers?

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.

samuellevy8• 13 years ago

I think that's a chicken/egg situation there.

corry• 13 years ago

Agreed. As is often brought up in PHP threads, the biggest thing is universal adoption of PHP in web hosting. People learning how to stitch together web pages aren't going to grab a VPS, learn the complexity of managing the server, and use something complex like Rails (where there's a language, a framework, and MVC to learn).

With PHP --> the newbie just has to FTP the files up and it works. Fewer variables to manage, fewer things to learn. You go from 0 to 60 much faster. Now, you probably will go from 60 to 100 much much slower than with a different stack, but that's a different discussion...

bradwestness4• 13 years ago

I agree, and I think that means it will be very difficult for any language that requires more understanding of OOP concepts to get started with will have a hard time competing with PHP in this arena.

dubcanada5• 13 years ago

Good luck! But that's going to be hard. LAMP on Windows is as easy as downloading a exe file and running it. LAMR (or what ever you want) will never be that simple. It's the nature of the language. They are completely different.

I'd like to believe maybe one day someone will commit the 6 months to make such a thing happen. But I really doubt it.

grimborg• 13 years ago

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

scribu2• 13 years ago

So, you're saying that you can buy cheap shared hosting with a Python server set up, where you only need to upload the files via FTP and it will just work?

rywalker2• 13 years ago

Deploying with FTP is harder than deploying with git.

knieveltech• 13 years ago

So you're saying you can FTP a full featured CMS to commodity hosting and it just works?

jonascopenhagen• 13 years ago

Deploying a PHP site can be done with the use of one or two apt-get commands. In Python I'd need to do that plus write WSGI-related stuff in a script, alter the Apache configuration, etc. Check out the instructions for Flask or Django if you don't know what I mean.

conradfr2• 13 years ago

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 ...

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.

nkozyra7• 13 years ago

But this is a different issue altogether.

If someone asks for product X without a language specification, you're probably free to create it in any language you're comfortable (although admittedly it would be stupid for a client to allow this).

PHP is not faster to write, debug and deploy than most other languages. It is faster to write, debug and deploy if you know PHP well and language X not as well.

conradfr2• 13 years ago

I guess it goes hand in hand. PHP is good enough for most of the jobs, cheaper/easier to host, and you get cheaper and easier-to-find developers

borplk• 13 years ago

"a language that still can't decide if 0 is something empty or just the number 0"

Beautiful.

nkozyra7• 13 years ago

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.

samuellevy8• 13 years ago

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.

nkozyra7• 13 years ago

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.

StavrosK3• 13 years ago

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.

antidaily• 13 years ago

Uh, yeah, do that please.

samuellevy8• 13 years ago

there's mod_python, which has never worked in living memory, and there's PyHP which... went into beta in 2008, and hasn't noticeably changed since.

nkozyra7• 13 years ago

> 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.

dubcanada5• 13 years ago

You can't get any easier then FTPing files. And maybe changing a config. That's all you need to do.

jiggy2011• 13 years ago

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.

coldtea7• 13 years ago

>I don't see PHP as any more easily deployable than Node, Rails or even self-contained Go/Gorilla.

Really? Rolls eyes.

PHP deployment = copy the files to the shared hosting area. Done.

Go even needs building a binary for god's sake!

And people paid Katz nice money to make RoR more easily installable.

nkozyra7• 13 years ago

That's really less about deploying than it is about setting up the environment.

PHP deployment = copy the files to the shared hosting center. Done.

Node deployment = copy the files to the shared hosting center. Done.

What's missing is the setup. Most shared hosting centers just preinstall a LAMP stack and call it a day.

donutdan41142• 13 years ago

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, it's still PHP, but a good framework makes those more complex PHP applications understandable.

If you're building a website (in any language) without a framework, you're doing it wrong...

papsosouid15• 13 years ago

If you are using a framework, then you've lost the "advantage" PHP had to begin with: simplicity. Once you are using a framework, everything is just as complex as with rails or django, so why not just use one of those?

And your last statement is terribly ignorant. There's tons of web sites and apps that are better off built without a framework.

donutdan41142• 13 years ago

I'm sure if you think of any successful web site/app they use some type of framework, even if they made it themselves.

ollybee• 13 years ago

"the only language that makes deploying a website effectively idiot-proof"

I work for a large web host and can assure you this is not the case.

coldtea7• 13 years ago

Have you compared to idiots installing RoR and Java apps on same host?

If not, then you're not assuring him at all.

samuellevy8• 13 years ago

I've worked for a reasonably sized (business) host myself, and yes - anything that's idiot proof is just waiting for a bigger idiot, but PHP is far easier to deploy for a non-programmer than anything else.

mwcampbell2• 13 years ago

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.

andyroid• 13 years ago

When doing freelance jobs, I've rarely had the chance to choose the hosting provider for the client as they in most cases already have a web site which they need to extend with certain functionality (web shop, blog, etc). Convincing them to switch hosting provider without obvious (to them) benefits is pretty pointless. Of course, your point still stands if the job entails creating a platform from scratch.

rywalker2• 13 years ago

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.

But McDonald's is still better food.

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!"

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.

"The easy path is often not the best path." -Me

alexjeffrey2• 13 years ago

"best" is a very subjective term. PHP is not the best language for making in-house web app stacks like many people on HN build, but it is the best language to deploy a basic marketing web page for the chip shop down the road. That's the point I believe this article is trying to make, and basically just boils down to "the right tool for the right job".

netmute• 13 years ago

Simply not true.

Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.

The article is talking about managed hosting, were that might still be true (Admins are incredibly conservative and stubborn individuals).

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.

In contrast, I can install and setup a complete Ruby server in about 15 minutes.

knotty662• 13 years ago

Is it really that difficult? The last time I had to install LAMP stack was on Ubuntu and it was something like:

$ sudo tasksel install lamp-server

jstalin• 13 years ago

Really?

apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-cli php5-gd

Takes about 2 minutes.

papsosouid15• 13 years ago

If you want to pretend that is all that is involved, then your argument suggests web development with haskell is just as easy to setup as with PHP:

    $ pkg_add snap

Well, that was easy.

IgorPartola10• 13 years ago

apt-get install libapache2-mod-php5, edit create/edit your vhost file, upload PHP files to wherever you pointed the vhost file, reload apache?

mgkimsal3• 13 years ago

apt-get install apache apt-get install mod-php5 apt-get install php5-pdo-mysql

whatever the packages are - there's about 4-5 core packages (yum/apt/whatever) or other packages like xampp that set up a default environment in about 5 minutes on most modern systems.

There's certainly a lot of configuration that can be done, but getting a LAMP system set up to allow PHP/MySQL to work is trivial these days compared to 2000.

Cue the puppet and chef supporters who would suggest scripted recipes for everything anyway. :)

bti• 13 years ago

It could not be any easier to get a LAMP stack up and running on a fresh server.

$ apt-get install lamp-server

knotty662• 13 years ago

I think you may need the caret at the end if you are using apt-get rather than tasksel directly:

$ apt-get install lamp-server^

darkxanthos2• 13 years ago

But that work is reused.

thegoodlab• 13 years ago

PHP "out of the box" is very easy, sudo apt-get install php5 mysql-server apache2.

jqueryin• 13 years ago

He could be implying shared hosting is the most common method of hosting. In these cases, they all tend to come pre-configured with a LAMP environment. No setup necessary for CLI scripts.

From scratch, everything is easy to install. I wouldn't say Ruby is any easier to install and setup than PHP. You're talking about installing something like Phusion Passenger on top of Apache. A LAMP stack takes as long as it takes to run `apt-get` or `yum install`. By no means is it 15 minutes; I'd say 5 to 10 with minor Apache configuration and a VirtualHost entry.

coldtea7• 13 years ago

>He could be implying shared hosting is the most common method of hosting.

He's not only implying it, he states it explicitly. No need to guess, the article is there.

ThomPete2• 13 years ago

And since most people in this world use managed hosting for their website projects thats the right thing to compare with.

Also you have MAMP which is as easy as it comes for setting up a PHP/mysql environment on your computer.

But the strength of PHP goes far beyond this simple point.

For developers it's very very simple to get started. The difference between writing a hello world app and a crm app isn't that big. Weaving HTML and PHP together with JavaScript, CSS, JS easy to learn with PHP.

I wouldn't even know where to start in Ruby or Python. Just too many dependencies before you can even get started.

So yes it's by any metrics it matter true.

Take it from someone who had to teach himself how to do it and have tried to get started with several languages.

coldtea7• 13 years ago

>Simply not true. Have you ever tried to install and setup PHP on a fresh server? It's almost as painful as writing code in PHP.

Which is so totally beside the point he makes, that I'm pretty sure you didn't RTFA.

The "market" he describes is NOT installing PHP from fresh on servers.

IgorPartola10• 13 years ago

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.

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.

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.

mgkimsal3• 13 years ago

The terms I've heard for this is "shared nothing" - no state is shared or stored between requests.

montecarl• 13 years ago

Isn't this true for any CGI program? I know that PHP is typically run via mod_php, but what you have described is true for any CGI program.

It is somewhat expensive to startup a new interpreter process per http connection. This can be alleviated by using FastCGI, but then the interpreters are long lived and are no longer completely independent.

IgorPartola10• 13 years ago

Yes, though PHP comes with a few goodies such as mainstream mod_php and FastCGI (which I prefer), and bytecode cache (APC). The implementation is pretty good compared to a ye olde CGI Perl script.

gngeal• 13 years ago

Somehow I don't think that the other languages prevent you from doing what you've just described. It's entirely up to you how you write your application. OTOH, sometimes you need some shared state, if it's handled in a careful fashion (stats collecting, anyone?). The last time I saw PHP, however, low-latency shared state was really awkward to handle.

bradwestness4• 13 years ago

Yeah, and other languages certainly don't require a separate server instance per application. I have about 25 .NET apps running on my production server at work and it's humming along quite nicely.

judofyr2• 13 years ago

> You can mess up and create a dirty execution environment.

Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.

> I detest writing code in PHP for many reasons, but the execution model is efficient

No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

(Added later: Yes, this isn't how PHP actually works, and that was kinda my point: parent's concept of "PHP execution model" isn't actually used in PHP because it's stupid! There will always be some things that you want to share (connection pooling, opcode cache) so even PHP isn't a "perfect" share-nothing architecture.)

It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.

IgorPartola10• 13 years ago

> Then don't mess up. It's not that hard. If you follow best practices (don't use global variables) you should handle this fine. I haven't heard anyone having this problem in Rails at all.

Sure, though how do you know all the library code you are using isn't going to mess things up for you? Granted, chances are small, but they are there.

> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

Use a cache for your bytecode to not re-parse all the time. Use a special purpose TCP proxy to keep connections open if that is your bottleneck (in most web apps it's not). Also, certain DB drivers let you have persistent connections out of the box.

> It's perfectly possible to write a shared-nothing architecture without dumbing it down to CGI.

It hasn't been done yet for the price that PHP offers. It is very limited in some areas, but if you go with the grain, it is very cheap.

My main point is that two different applications cannot share an interpreter in RoR/Django/nodejs. This leads to overhead which is not there for PHP. Places like Heroku and Google App Engine try to be clever about this. You can technically shut down interpreters that aren't used frequently, and spin them back up when many requests come in, but guessing when to shut things down and spin them back up is tricky. This is why Google App Engine is so pricey: they suck at figuring this out. But even if you have a great way to figure it out, you are still going to have unpredictable performance, and the cost of waking up/spinning up an interpreter is fairly high.

polyfractal2• 13 years ago

> No it's not. You'll have to re-open connections to databases all the time. You can't use keep-alive to external HTTP APIs. You'll have to re-parse the PHP for every request.

What? This is all factually incorrect.

1) PHP has supported persistent database connections for ages. The fact is, persistent DB connections aren't really that great for websites, where you need a few resources quickly and then nothing for a long time. Having 10,000 idle DB connections is a great way to eat up resources. But you can do it.

2) PHP can use cURL's multi-handles, providing a per-application keep-alive connection pool (e.g. see Guzzle: http://guzzlephp.org/tour/http.html#managed-persistent-http-...).

3) While not part of PHP itself, most serious PHP applications use something like APC, which caches PHP opcodes to prevent constant reparsing.

papsosouid15• 13 years ago

>but the execution model is efficient

It is quite the opposite. It is incredibly inefficient, running hundreds of copies of the exact same code, building up an entire framework of objects to use for a single request, then trashing them all to do it again from scratch on the next request. It is easy for beginners, which is why it is so popular. But that is not the same as being efficient.

IgorPartola10• 13 years ago

So what happens when you configure apache to run 100 processes of your Django code? If 100 clients want to view a web page, how many copies of the request object are floating around?

Or are you talking about parsing the code? At that point, something like APC would help immensely.

kyllo• 13 years ago

That may be a reason why, but far from the only reason why, Heroku is more expensive than a cheap shared hosting provider. Heroku provides a lot more than just hosting files and running server instances. They provide all kinds of value-added services in deployment, logging/monitoring, security and performance auditing, package management, git integration, database choices and plugin apps, etc etc.

darkxanthos2• 13 years ago

Why is PHP so threatening to so many developers? Don't use it. Don't take jobs where it's the primary tool.

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.

papsosouid15• 13 years ago

>Why is PHP so threatening to so many developers

Because we inherit the horrible mess of shit PHP developers leave behind when the company finally releases they've painted themselves into a corner and can no longer move forward because every time they try to fix a bug in their software they add two more.

>Don't take jobs where it's the primary tool.

It is so widely used that even avoiding jobs where it is the primary tool, you will still almost certainly be stuck dealing with some PHP mess.

dubcanada5• 13 years ago

"horrible mess of shit PHP developers" has nothing to do with anything. Horrible mess of shit Ruby developers can be just as ugly if not more.

jpb0104• 13 years ago

That "mess" your talking about is called technical debt. Technical debt is a real thing in any language not just PHP. I usually try to take this approach: make that "mess" less of a mess. Even just a little bit less of a mess. If not for your sanity, at least for the next developer behind you.

nir2• 13 years ago

True story: Worst code I've ever inherited in my life was in Python / Django.

pavel_lishin• 13 years ago

Another reason, aside from inherited-mess, is that if you're an independent contractor, promises of cheap PHP projects make it harder to charge for quality work.

nnq2• 13 years ago

Can you spot the outliers here?: "where PHP has excelled with projects like Wordpress, Joomla!, Drupal, Magento, Moodle, PHPBB, and so many more.".

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 byte hard!. 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!

ThomPete2• 13 years ago

That can be claimed for many other environments too. Ever tried to go outside the beaten path of Community Server?

It's an inherent issue with frameworks not with any particular language IMHO.

dubcanada5• 13 years ago

Not sure where you work, but where I work the entire reason we are able to do websites quickly and efficiently is because of Drupal, Wordpress. We are very very rarely over budget/time.

Sure they have problems, but so does Rails, and Django.

bhughes• 13 years ago

Based on experience, I would agree with you on the Magento front (as my perpetually-in-the-planning-stages blog "I Hate Magento" will attest), but I have yet to find anything more usable (and customizable) for larger scale operations. I know there must be something less bad. Thoughts, anyone?

meaty2• 13 years ago

Agreed - its a stinking turd, but at least it's not oscommerce :)

jdavis703• 13 years ago

I used to work in a Drupal shop, and all our Drupal projects were completed on time and within budget. However we also had good project management, so there weren't any 11th surprises about customizations that would be difficult to implement in the "Drupal way."

nnq2• 13 years ago

...agree, there has to be a way to do Drupal "properly", otherwise it wouldn't be so popular. But you have to agree that Drupal does need quite a lot of "special care", too much for my taste, in the way of planning and doing things its way and knowing that stuff will start randomly falling apart once you start working "against it". Things that are either "just a blog engine / just a CMS" (Wordpress) or "just a framework" (pick your fav here) are much harder to misuse and turn into a total mess. For me the whole point of using PHP is "fail fast, fail cheap, be 80% idiot-proof", and I just use Drupal as an example of outlier PHP project that went very, very far away from this mantra, but then again, maybe going away from this mindset is what you need for your projects.

btbuildem• 13 years ago

> It works, out of the box, for people who don't know what they're doing

here's the worst of all the bad reasons right here..

coldtea7• 13 years ago

Absolutely nothing bad about it.

It's called empowering people.

pettazz• 13 years ago

Because only experts should be allowed to write code and try to build things? I'm sure you were writing shitty broken apps before at one point in your life, just to learn by experience and get better.

kennu• 13 years ago

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.

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.

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.

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.

graywh• 13 years ago

This cuts both ways. My RoR apps use gems that require other non-ruby libraries to be installed.

byroot• 13 years ago

While I agree with you, I don't think PEAR/PECL a good exemple. Even with a good Gemfile if the libxml2-dev is not installed you will not be able to bundle your Rails app which use Nokogiri.

Where the argument of PHP run on any cheap shared hosting fail for me is more about the php.ini config. You can't rely only on the PHP version to know if your app will run.

davedevelopment• 13 years ago

Composer (getcomposer.org) and Packagist (packagist.org) are largely a popular replacement for PEAR, though once you need a C extension (PECL), you're right, it does become a pain.

dubcanada5• 13 years ago

You really shouldn't be deploying SASS/SCSS/CS/what ever. You should be compiling that locally and deploying JS/CSS.

JonnieCache3• 13 years ago

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.

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.

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.

I'm happy to be lectured to about why this is wrong.

bradwestness4• 13 years ago

I don't think it's so much that it's considered an upside, but rather that it's basically impossible to displace PHP with something better unless the thing you want to replace it with is equally easy, or easier, to implement.

nayefc• 13 years ago

Maybe "low-skilled people" can just stick to Wordpress?

ojr• 13 years ago

Low(er) skilled or people with not a lot of computer language experience as I see it, should be using the language that makes them the most productive, in most cases this is PHP thats the simple truth, I have a programming assignment due in my college data structures in java class, if you really want to see a horrible mess

JonnieCache3• 13 years ago

The question is, are we defining productivity as "the developer can bill and move on as quickly and easily as possible" or is it "the client's business needs are served as well as possible"?

talkingquickly• 13 years ago

Very much agree, particularly as it seems to be the case that "low-skilled people can use it" rather than "low skilled people can use it well."

I'd argue while it's very easy to get started with PHP, it's very hard to build some of good quality with any significant functionality compared to say rails/ django (ignoring framework != language).

Not at all suggesting it's impossible to build good quality apps in PHP but that it's very easy to build bad ones so to build a good one, the programmer already has to be pretty good, making it a poor choice for low skilled people use imo.

EwanToo• 13 years ago

You're right, if we took this attitude in civil engineering or medical science then it'd be a problem, but hey, it's not those things, so why waste the time, money and effort that it would need?

You say "obviously not every web project is as important" as civil engineering, but I'd put it the other way "Almost every web project is not anywhere near as important" as civil engineering.

People build Ikea shelving units in their home all the time, without a civil engineer being involved.

JonnieCache3• 13 years ago

Let's torture this analogy some more.

Ikea shelves often break, and thus commonly need replacing every couple of years. This might end up with a higher total cost/kg/year for holding your stuff up in the air, compared to hand building your shelves out of oak or whatever.

Of course, many people move apartments each year anyway, and the old shelves will not fit in their new apartment. So it makes sense to use ikea shelves in this case. Unless of course, the handmade oak shelves were modular and could be easily reconfigured in a way that the pressed-fibre ikea shelves couldn't.

The real problem comes when your ikea shelves fall down, breaking all your stuff. In which case, you were an idiot for putting your important stuff on ikea shelves. In this scenario, you may wish to hunt down and disembowel the interior decorator who told you the ikea shelves would be fine.

So yeah, the right tool for the job. Who'd have thought it? ;)

Personally I won't be giving up my life as a designer of premium bespoke home storage solutions for a job on the checkout at ikea.

nir2• 13 years ago

If building websites is like building bridges, you're right.

I think it may be more like communicating. In that sense, English is "better" than Esperanto, even though it's not as well thought out, simply because more people can use it at some level.

alexjeffrey2• 13 years ago

I think you may have missed the main point of this article. As an example, I can code to a reasonable standard in Ruby, C and PHP but I mainly work in PHP because if time or budget is low I can speed up development by writing horrible procedural code or other hack-jobs. I'd love to build MVC applications with well-structured architecture all day but many clients just won't pay for backend nicety. From an engineering perspective this is a horrible trade off but from a business point of view it's just what needs to be done sometimes, and I don't believe any other platform offers this.

PHP generally allows developers to just get up and go, both in terms of installing it on a server and building an application, and requires minimal learning. Unfortunately that does mean you end up with a large number of substandard developers, but at least they're getting things done.

EDIT: it's also perfectly possible to clean PHP up using e.g. autoloaders and the builtin interfaces and spl classes, if you want to work cleanly - this capability seems wholly underused outside of frameworks and I hope it gains more attention soon.

dicroce• 13 years ago

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...

robomartin2• 13 years ago

These threads always get "interesting" don't they?

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.

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.

There's a huge difference between holding a cat by the tail and watching someone else do it from afar. Huge.

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.

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.

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.

papsosouid15• 13 years ago

>However, when faced with having to do a benefits analysis it is almost impossible to not choose PHP these days

For what? We were already heavily invested in PHP, but still our benefit analysis had it second last, only ahead of javascript. What benefits were we missing?

robomartin2• 13 years ago

Each organization is going to be different.

If you have a team that already rocks on PHP, migrating people to Python is likely to be a problem.

Depending on where you are located, finding good Python programmers could be difficult (stats: over 10x more PHP programmers than Python.

If your project is pretty far along, translating to Python might carry with it a non-trivial cost.

In general terms I think it might be easier/cheaper to launch an MVP in PHP with a sensible framework (like Yii) and then migrate to Python + web2py or Django for the "real" product.

I prefer Python, but it is hard to ignore job market statistics when considering what it might take to put together a team.

I'll go out on a limb and piss off a bunch of people in the process. I'll venture the thought that most PHP-only programmers are really bad programmers. Someone not formally educated in CS or having no experience in a variety of languages (and paradigms) before adopting PHP will probably be "challenged" as a programmer in more than one way. I have a feeling that, because of the nature of the language, a larger percentage of Python programmers are really good "traditional" programmers with a good balance between theoretical and practical knowledge.

Let the flaming begin.

kbenson2• 13 years ago

What type of benefits/features would you break PHP/python down to when making that choice?

I'm wondering if it is also influenced by long/short term view of the benefits. IMO PHP has extremely high short-term benefits, but many of those break down when taking a longer term view on development and maintenance (mainly because the benefits for one often end up being liabilities for the other).

gnuvince• 13 years ago

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.

mwcampbell2• 13 years ago

The one technology that's nearly as ubiquitous on shared hosts as PHP is CGI. Plain, one-shot process-per-request CGI.

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.

I think the Go language would be a good fit.

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.

sneak• 13 years ago

Except that my web host runs freebsd.

mnazim• 13 years ago

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

mqzaidi• 13 years ago

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.

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.

I can argue that shell scripting is the best programming language by this logic.

taproot• 13 years ago

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.

An incredibly bad and impossible to maintain website, but a "dynamic" website none the less.

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.

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

Related Stories