Monday, January 12, 2009

Why PHP won

PHPWhen I first learned to program on the web, Perl + CGI was the dominant platform. But by the time I was building my first websites for commercial use, PHP had taken over. Since then, PHP (as part of the LAMP stack) has really been the dominant development platform, at least in the free software and startup worlds. Through my platform choices, I have forced many people to learn PHP and to work with it on a regular basis. Some of them are probably still cursing my name, because - let's face it - PHP can be pretty painful. As a language, it's inelegant. Its object-orientation support is "much improved" - which is another way of saying it's been horrendous for a long time. Writing unit tests or mock objects in PHP is an exercise in constant frustration.

And yet I keep returning to PHP as a development platform, as have most of my fellow startup CTOs. This post is about why.

Let's start with some circular reasoning. The number one reason I keep coming back to PHP is that it has overwhelming community support. I've written elsewhere that success in creating a platform is "becoming a function not of the size and resources of the company that builds it, but of the size of the community that supports it." When we started IMVU in 2004, we could rely on a staggering amount of open source software that jumpstarted our initial product offering. From e-commerce to blogs to photo galleries, we benefited from tens of thousands of lines of code that had already been battle-tested. Add onto that the incredible amounts of infrastructure code that we reused, and we were able to bring our product to market months earlier.

But that just begs the question: why does PHP have the most thriving community? It's an example of an information cascade - as PHP started to pull ahead of the platform pack, more and more people started working on it, increasing the size of the community and therefore making it more likely that even more people would choose it.

So, to understand how that cascade got started (and keeps going), we have to look at several key attributes of PHP. You'll notice a pattern: most of the key features that enabled PHP's success are considered among its defects by experts in language design. Ironically, as PHP has grown up, its designers have been busy "fixing" these shortcomings. It remains to be seen whether they will be able to do so without losing what enabled them to succeed in the first place. Or, perhaps they'll create an opening for another web platform to start a new cascade. If that happens, I expect you'll see some of these attributes in that new challenger:
  1. Speed of iteration, thanks to reload-pages-every-time. CGI scripts had notoriously bad performance. That's because for every page request the web server had to spawn a new interpreter process, load the script, and return the output across process boundaries. So when people started using Apache's module system to build better web application platforms, it was a natural that they'd try to make the system more efficient. Take mod_perl, for example. In that system, the first time you loaded a script to handle a page, the whole script (as well as associated data) were kept resident in memory. The next time you needed to handle that page, you could take advantage of caching for excellent performance. There was only one real disadvantage: when the script source code changed, you needed to restart apache so that it could reload. This sounds like a good trade-off, but it turned out to be a classic sub-optimization.

    Memory-resident code made it slightly slower to iterate on scripts. Every change required a server restart. Even on a single server, those extra few seconds between iterations is costly. Writing code with PHP, even though the language is crufty, feels fast, because of the tight write-test-debug loop. Plus, with memory-resident code, it's pretty easy to forget which version of the code is actually running at any given time. The stuff in memory is invisible - you can't double check it. As a result, you have to be a lot more careful.

    This feature also supported multi-user environments much better. You could give someone a directory on your server as effectively a simple sandbox. You didn't need to worry about them breaking your server configuration or restarting it while you were in the middle of something important. This made it easier for ISP's to offer PHP hosting on shared servers, too. All of which meant it has always been exceptionally easy to get started with PHP. And when considering a new language or platform, the getting-started barrier is probably the single most important factor.

  2. Direct mapping of outputs to inputs: URL's to files, code and presentation intermixing. PHP has a number of other seeming defects that make it easy to understand what's happening in a PHP application. This allows new people to get integrated into an existing PHP project faster. For example, I have repeatedly taught PHP to complete novices in several companies, including people who had never before programmed at all.

    Almost every PHP-based website is burdened with ugly URLs that contain the name of the file that implements each page. This is considered bad practice, because URLs are supposed to be about resources (meaning the content of a given page), not implementation. In theory, you should be able to completely change platforms, languages, and servers and not have to change your URLs. However this approach, while elegant, has a major drawback: it requires non-trivial understanding to figure out where to find the code for a given page. Just consider one way this is commonly done: having a table of regular expressions somewhere that maps URLs to pages. This sounds simple, but in order to use it everyone on your team has to: 1) know where to find the list of mappings and 2) be able to read regular expressions correctly. Every other system I've seen has some drawback like this. PHP has no such compunction: the name and location of the file are hanging out in the open, for everyone (including your teammates) to see.

    And then let's consider what happens when you get to the implementation file tiself. PHP encourages one of the worst programming heresies of all: intermixing code and presentation logic in a giant mish-mash. If you're emitting HTML, as 99% of all PHP apps are, it's just so damn convenient to throw in PHP tags along with your layout tags, all inline on the page. In many ways, this is a maintainability nightmare, but it has a compensating benefit. In most cases, simple changes are simple to make. At IMVU, when we'd hire a new engineer, we could get them to ship code to production on their first day, even if they had never programmed in PHP before. That's simply impossible on most platforms. That benefit carries over through the whole life of a project. The vast majority of features are actually only a few lines of code. All the difficulty and effort is in finding the right place to put them. PHP's transparency makes that easier, encouraging more experimentation and fine-tuning.

    All of which leads to a non-intuitive conclusion. PHP shines on one of the most important criteria for platform selection: readability. Yes, you heard me right. Even though PHP's syntax is an inelegant beast, the overall platform is impressively readable.

  3. Incoherent (but huge) standard library. These days, successful programming is as much about processing data as creating algorithms. To be a good data-processing language, you need a large standard library. PHP has always scored well on this count, with lots of support for database drivers, URL parsing, HTTP fetching, regular expressions - you name it. And this all came bundled up in another bad practice: a big monolithic interpreter. For most of its existence, PHP didn't have a standard package-distribution system or very good module support. As a result, important features that were used widely almost had to be bundled into the interpreter itself. Although this was annoying for sysadmins, security consultants, and language purists (and for those who had proprietary modules that couldn't be bundled), it was a huge boon for developers. It meant that the PHP brand stood for the same set of tools always and everywhere. If someone offers you a library or script, it's a huge benefit to know that it will run in your environment, without having to worry about dependencies, which leads to a lot more code sharing and code reuse.

  4. Bad OOP support. PHP began, as many scripting languages do, with pretty primitive language features. It was especially criticized for its lack of object orientated programming support. Although recent versions have added robust objects, inheritance, and interfaces, for most of its life PHP's objects were little more than decorated dictionaries. This is another feature that makes language purists cringe, but was key to PHP's success.

    One of the overriding benefits of OOP is encapsulation: the ability to take a chunk of code and data and put them behind an interface. At the cost of a little extra indirection, you can organize your code around a series of long-lived objects, each of whom communicates with the other objects in simple, easy-to-understand ways.

    In practice, though, this extra indirection imposes a steep penalty in transparency. Most PHP scripts are not long-lived, meaning that every object has to be constructed, used, and disposed for every request. And most PHP servers are run in a stateless mode, delegating storage to other processes like memcached and MySQL. So, in many cases, there's not much readability benefit to constructing an object, when all it is is a lightweight wrapper for external data access methods. A "module" of related functions does the job just as well, and is a lot easier to find when you're trying to understand how an application works. This is yet another way that PHP supports non-programmers well.

    There's another big benefit: one of the major strengths of the web is that it auto-encapsulates code behind URLs. That's part of its magic, and PHP takes advantage of it. Everything is request-oriented, short-lived, and stateless. A PHP script is like an object itself, encapsulating a bit of functionality behind an interface defined by HTTP. It's one of the most effective paradigms for software devlopment in history. The platforms that win on the web are those that mirror its fundamental structure, not those that try to morph it into a more traditional "elegant" shape.
I'll close with one last thought. The inimitable Paul Graham has an excellent essay called The Python Paradox in which he argues:
...that you could get smarter programmers to work on a Python project than you could to work on a Java project.

I didn't mean by this that Java programmers are dumb. I meant that Python programmers are smart. It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.

Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it.
As always, Paul is right. So, given that PHP is so popular, you might think it wouldn't be a great choice for companies that are trying to hire great programmers. Given that startups depend on superstars to survive, why stick with PHP? In my role as a CTO, I've always tried to choose the right tool for the right job. The IMVU downloadable client, just to name one example, is written primarily in python. This let us hire extremely high-caliber programmers to work on it. You might then assume that our backend was written in mod_python. But it's not.

It's easy to forget that these decisions need to be made, not on a language-by-language basis, but on a platform-by-platform basis. PHP may not be a great language, but the platform it enables does attract one particular kind of great developer: the cutting edge web gurus who work primarily in javascript, DHTML, and Ajax. For them, PHP is an ideal language precisely because it gets out of their way, allowing them to build a simple foundation for their complex and beautiful browser-based cathedrals.

When simple things are simple, and hard things are possible, great people can take it from there. So here's to the team that built PHP. Thank you.
Reblog this post [with Zemanta]


  1. Good article, this is exactly the reason I'm still primarily a PHP developer rather than Ruby or Python. Although I've enjoyed learning and using other platforms/languages, it's the fact that PHP has grown around building websites rather than satisfying the intellectual needs of Computer Science researchers.

    Other languages are far superior in terms of ease of writing and producing good-looking code, but PHP’s strengths appearlater on. This article by Rasmus Lerdorf is a good example of PHP playing to its strengths:

    It’s the above reasons why I’ve built in PHP (it was very nearly Ruby), PHP is by no means a well crafted, beautiful language, but it is a great tool for building web apps.

  2. Also, PHP is the new BLACK

  3. You're right php can get ugly when used inline with html. And believe me its a maintenance nightmare, but once you start with smarty or other template languages. You'll see its elegance its beauty, mix in some MVC and you're good to go.

    PHP can do what no other language or framework can (albeit django). Keep HTML HTML and Javascript Javascript. Ajax is 10 times easier with php than any other language.

    With php you just need to put in effort to stay on the path. Because you can get lost if you get of the PATH.

  4. You make some interesting arguments, that are starting to remind me of the rise of worse-is-better.

  5. Hi - I am not a PHP programmer (anymore - no web) but I find your points very well written and completely agree. Congrats!

  6. To me on of PHP's best attributes is that its 'C' for the Web. There are a lot of C and C++ programmers out there who have had to move to web based development and Python and Ruby are not 'C'.

    PHP has an almost complete CLIB implementation which means I can do sprintf calls without having to think about much. So for an old 'C' guy like me PHP is a great language. And given that the browser-side language, JavaScript is also syntactically 'C' for the most part, its a very easy transition.

  7. Yeah, php can get the job done, but holy god it can be an awful language in which to write. For those that are interested in something a little better, i suggest checking out

  8. > ...the cutting edge web gurus who work
    > primarily in javascript, DHTML, and Ajax.

    You should've put this at the beginning.

  9. You should try Python. I've been down both paths, and there's no comparison.

    Remember, when all you have is a hammer...

  10. Do you think that the long-term maintainability and reliability costs that result from using PHP are outweighed by how much time and money it saves you in the beginning? For a startup, it seems like that might be the case, since the long-term doesn't matter if you can't kick ass in the short term. But it also seems like it could severely limit your long-term options: Once you've actually managed to make it through the first couple years and build up a customer base, you now have to invest thousands of man-hours into aggressively refactoring, and replace reams of PHP code with code that's secure, maintainable, and reliable.

  11. Nice article. However, it made me remember that I'm tired of technology arguments. Don't get me wrong, the right tool should be used for the right problem. But I think debates about which language, which operating system, even which editor (emacs, vim, Visual Studio) can go on forever.

    I've observed successful companies that use PHP, and some that used Ruby on Rails, and some that used Django (Python), and some that used and .... (the list goes on). In the end, these are tools like hammers and nails. What a person builds with their hammers and nails is what matters.

  12. very good article! You're absolutely right in every point. I personally think that the opinion about PHP in the web-developer community is way too negative. Everybody should read your article

  13. A lot of arguments, I agree with some while having a different stance on others, however I would like to just note one point (and to make this clear in advance, I used to use php, then switched to ruby and have not really regretted this move at all):

    You wrote:
    "To be a good data-processing language, you need a large standard library"

    But this is a big problem. As a user and programmer, I would like to have only one way to achieve what I want, and I want to have the WHOLE community agree on this way. I dont really care what way is used, and I hope the community would have standardized libraries (no matter the language)

    I really do not like to make choices. If I am forced to make choices, I will stop using the bad choice, unless I am forced to use it. And I think a bad choice, a bad library, a horrible API, lack of documentation etc... will make the foundation weak.

    It is one reason why I like ruby. I can design with my brain coming first - the way I like it. And changing design is not that difficult (just quite boring and sometimes takes quite some time...)

  14. @Kevin - I think you are asking the right question. If I had to do it over again, I would still have used PHP, but I would have used it differently. I believe that if you practice TDD, continuous integration, and active refactoring from the start, you can write maintainable code in any language.

    Of course, what I hope is that some day we'll all be able to work on a web platform that is much better than the ecosystem of PHP. I hoped this article might give people some ideas of how to make that happen.

  15. I remember when php started getting popular 10 years ago. Remember back then the only other options were perl and cgi. PHP was way better than them.

  16. You forgot to mention how awesome the documentation on is.

    The function examples are great and there are always useful comments with even more examples.

  17. Interesting post. It seems that the primary issues with PHP is its un-namespaced library and syntax. Has there been an effort to create an elegant DSL that writes PHP code? A meta language may reduce the frustration experienced by Pythonistas and Rubyists

  18. It's interesting to find this kind article now, as PHP has evolved much farther than what you described.

    The proliferation of high quality, best practices frameworks - such as CakePHP (rails for PHP), Zend Framework (my personal favorite), Simfony and Seagul just to name a few. Those implement useful design patterns such as MVC, database gateway and other abstractions which make maintainability much easier.

    Most of the problems you alluded to can be easily avoided if you are familiar enough with your options - for example, a front controller can easily control your URL scheme and direct to controllers/actions instead of mapping URLs to actual file names (do people still do that?)

    There are also solutions to performance issues resulting from abstraction and runtime compilation (check out op-code caches such as APC).

    The only relevant "issue" you described is the large library of inbuilt functions. While it's true there are some inconsistencies with the naming scheme, those functions are a large part of why PHP is so successful - they provide easy to use and performant shortcuts instead of reproducing all the provided functionality yourself. After you get used to it, it's a big plus.

    To cap - I'm glad you decided to give PHP the big thumbs up, but it can be much better than you described.

  19. Old development? Fine, stick with PHP. New development? Pick something your programmers LIKE. In my case that was Python. I've been able to attract stellar programming talent just by using Python + BSD. The PHP developers we were hiring before were hard to find -- 99% of PHP "programmers" are absolute trash that would flunk the most basic real programming class (C, for instance).

    Yes, Python developers DO tend to cost more. In my market, I can get a PHP guy for around 40,000 a year. A "senior" PHP gal for around 55-62. A "senior" Python developer runs me about 70-95k+. They both can get the work done, but the Python folks are happy as hell. It doesn't seem to matter to them what awful projects they get thrown on, they get to use languages they ENJOY. Very few "senior" PHP guys enjoy PHP to the point that Pythonistas enjoy their language and it shows.

    Someone gets good at Python because they enjoy the language. Someone gets good at PHP because they have to. There is a stark difference between both types of employees.

  20. How can you ignore the sandboxing of mod_php and mod_perl which allowed mod_php to be installed on shared web hosts?

  21. I have a hard time believing that this article and most of its comments are not part of an elaborate joke.

    PHP is a terrible, ugly, bloated language. Sure, it may trump old CGI scripts .. but who even mentions those anymore. mod_perl, python, etc are far better languages in multiple ways, many of which you laid out in our article finely. I feel as though this article is actually making the case AGAINST PHP.

    One of the biggest pros you attribute to PHP is its community. Honestly, the PEAR database is nothing compared to CPAN. There are also a host of community sites dedicated to perl, and equally as many for the other prominent internet languages. Sure, your generic search of google for "how to create a dynamic webpage" will list you hundreds of thousands of sites referencing PHP, but that doesn't mean the community is top notch.

    Sure, PHP may have helped to explode the web scene when it was first introduced, but I think the real developers are quickly realizing the .. for lack of a better word, awesomeness of the other languages.

  22. Your post reminds me of that joke about the problem with Texas ("It's dusty and it's filled with Texans").

  23. you can write crappy code in any language. the fact is PHP is a WEB LANGUAGE. Written specifically for the web. It's flexibility allows for slop and "novices" to produce slop (cough! wordpress! cough!). It takes at minimum 5 years to be a decent PHP developer. On the other hand, I worked with one that claims 12 years experience and he might as well have been writing in crayon. In the end, it's not the language, it's the programmer.. and good programmers take the path of least resistance.

  24. PHP certainly has it's place for some scenarios, like small quick scripts, but having worked with php for 10 years and then switched to python and recently joined the django bandwagon I must strongly disagree with you.

    I'm happy PHP existed 10 years ago, I think it got a lot of people interested in web development when the alternatives were monsters like ASP and JSP. But today I believe that ruby and python, with RoR and Django are most definitely the best ways to go for a startup business that wants to get productive.

    Sure, one can argue that facebook and flickr are great apps built in PHP, but do youthink they would have used it if they started off today? I certainly don't.

  25. I am CTO of a SaaS vendor, and we use PHP. Oh, PHP has its warts: inconsistent syntax and variable ordering and a few other faults. But at the end of the day, PHP runs 24x7 under heavy loads without crashing, it's excellent documentation offsets the inconsistent APIs, and the simplicity of programming with the "everything is a string" makes it trivial to deal with many different types of data.

    PHP provides decent performance for dirt cheap, is easily understood, and if structured correctly, can scale to very large projects easily thanks to its "share nothing" approach.

    Having spent the better part of 10 years writing large projects in PHP - I love it!

  26. I've been a programmer for almost 10 years, when I need to use a scripting language, I choose the best tool for the job.

    Python is good for system administration, PHP is great for Web development.

    If you are a Web developer, PHP is powerful. If you are a Sys admin, Python and Bash-scripting gets the job done.

  27. Been using PHP, Ruby and Python for years now. I'm going to have to say that I prefer Ruby as a language (but Python is right up there as well)... and Rails as a web framework.

  28. Almost every point in this article is why I don't use php anymore.

  29. The great thing about PHP is that you can do ANYTHING -- really, anything, that can be done on the web by a website. You can do it very, very quickly, and usually with support from existing libraries. And it has been proven to scale horizontally, to the moon.

    As for Ruby, it's a cute language, I admit. I love the design of Rails (and have been using symfony PHP for a year now because of that.) I haven't had a reason to try Python, but I certainly know Java and C# and ASP.NET pretty well. PHP is a much better choice for user-interface-oriented web programming. It simply reduces the amount of effort you need to accomplish your goal, and can still scale.

    Why is PHP just an easier way to get things done?
    1. useful, huge ecosystem with amazing sample code
    2. no-theory-bullshit to get in the way of program logic. PRAGMATISM at it's best.
    3. lightning fast edit-compile-test loop (edit-test)
    4. Easy to set up, scale, and migrate between infrastrucure
    5. it doesn't put new and idiotic metaphors on top of the web -- the web is it's metaphor. (unlike, say, ASP.NET which is godawful)
    6. super-helpful associative arrays very closely mirror database-style data. I tend to recreate them in every language I use.

    There are things that PHP is not great at -- systems administration, realtime services, embedded programming, whatever. But for plain old data-driven website, PHP never loses site of the simple fact -- it's just a freakin' website. Get it done and move on!

  30. Why is "writing unit tests or mock objects in PHP an exercise in constant frustration"?

  31. Where's the evidence that PHP "won" or is even winning? It certain doesn't have, say, the dominance in web apps that C++ has in desktop app. Does anyone even believe that >50% of web pages are served by PHP? Facebook uses it, but not Amazon nor Ebay nor Google nor [you-name-it] do.

    In fact, the data ( show that PHP's adoption flattened in the middle of 2005. Well, web development has continued to grow, so it must be growing elsewhere...

  32. Excellent article. I've been working in PHP for much of a decade now and maybe I'm in the minority, but I truly like it for a variety of reasons, but the chiefest is likely your point at the end of the article: it gets out of my way and let's me focus on the other elements of a project including interface, client-side scripting, etc. I've used Python and Ruby before, too, when required of me but I always return to PHP if given the choice by a client.

  33. I tend to think that it's used, not primarily because it's quick, but because there is such a low barrier of entry. Tens of thousands of lines of codes that have been tested means very little if it could have been done in much less (IE: Wordpress, osCommerce, etc). Just because it works, doesn't mean it's good or maintainable. This is where the divide happens. I get very frustrated having to fix all of the 'PHP Programmers' code out there. They mix/match examples from online, and then try and piece it together to fit their needs. They don't know what they are doing, and at the end of the day can't support or maintain what they did.

    This is not a sweeping statement, by any means, as I know there are very many awesome PHP programmers out there. I have just found myself to be happier when building in Ruby as it is so much more elegant and maintainable (even outside of Rails). To me, it's also about being proud and satisfied with your work - not just putting something together for the sake of putting it together.

    The 'large community' (quantity) doesn't directly correlate with quality.

  34. Eric.. agreed.. you make some good points, specifically re: PHP scripts emitting crufty URL's (I'd say the same goes for Perl) - when required to reverse engineer a script - it's good to have context from the URL.. Enough about that.

    After reading your post, I got to thinking. Have people thought of 'what programming language to use' from a different point of view. The one I'm proposing is this one. What *scripting* language enables faster execution code for the hardware you buy. To ask the question another way - does it make sense to consider that a particular scripting language will execute faster on cheaper hardware? Or is the cost of *other* engineering resources too high(you already alluded to some in your blog) to count pennies?
    I'm curious.

  35. I think several of the commenters here not only dont know enough about the context of web programming, and are relating specious ideas, but - sadly - they are in the target audience that Eric was talking at, and they've missed the points sent directly their way.

    If you're using big frameworks in PHP, you are almost 100% wrong to be doing so. PHP fits inside frameworks, it doesn't implement them. Java (as one example, probably the best one right now) is a far far better language for framework building. PHP does it "OK" but there's really no excuse not to be using J2EE (either full on, or customized) if you're going that way.

    PHP is better than that; it does simpler things more simply. Use it where it's strong, not "wherever I am able to".

    YMMV, of course :).

  36. Hello Eric Ries ,
    Thanks for the great blog. I like your style of posting and useful information
    Which you always provide. Your post is really knowledgeable...

    Thanks Again...

  37. I am in the same position that I have to decide whether to use PHP or another one of those MVC frameworks (Rails/Django). As much as I wanted to personally code in Django/Python, the benefits of you mentioned above made me decide to use PHP. All of my team members are not dizzied by the html/code mixing so we do not use any PHP templating that will add another abstraction layer to a really simple request-response scenario.

  38. I've been programming PHP for 6-7 years, I've also worked with ASP.NET but didn't like it as much.

    PHP can be ugly and a complex scripting language. When you begin to use it with a nice framework like Zend Framework, you have something much more powerful, clean, and organized. In my opinion, Zend Framework IS what makes PHP a real programming language.

  39. I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading. Nice blog. I will keep visiting this blog very often.


  40. Perl is the best scripting language for Text processing and handle regex. I have posted few articles related to those at my blog

    Also Perl's Cpan has lots of support that I don't even need to think extra while developing project. I didn't find such help on other programming language except Java and .NET

  41. what a great site and informative posts, I always look forward to new posts.

    Web Art Sense Team

  42. Great article, I've used many different programming languages, but for web development, I think PHP definitely takes the cake

  43. Really nice article i like your article very much. Its fact and php is also nice programming language

  44. It's PHP that brings me to the world of web developing.
    I haven't yet tried neither ruby nor python. But I will always go with PHP only because of my loyalty to it.

  45. I like this article. it is very useful to me.

  46. Really I am agree with you this article. It is really great article.

  47. Interesting... makes me wonder should I learn PHP now?? ;)

  48. What an amusing article. I love programming in PHP and agree it has won (as of the moment). However, I gotta say, let's not knock it too much because bad programmers can produce bad PHP code. I for one can produce lovely PHP code when I take/have the time. And I produce bad PHP code when I don't have/take the time.

  49. Just a shout-out for python, here -- I'm one of your 'bleeding edge of the web' gurus, but *whenever* I do something server-side, it's python.

    [also I think your 'python paradox' doesn't really hold in my experience -- python is really easy to learn...]