Thoughts on PHP

I had lunch today with Terry, we discussed a bunch of things. Many points and counter points were discussed.

One thing that I’ve known for a while and (he’s known for even longer), that I’ve wanted to say is this:

if you have to develop for the web, and you don’t know PHP, you should change that

I’ve used Rails, Java, Python, Perl, and maybe a few others for web development. These projects were prototypes, working projects, or simple hacks. In my experience, PHP has the best architecture for web apps that need to be up and running quickly and then stay up. It runs on just about any inexpensive hosting provider out there. If you put a tiny amount of effort in, it can even scale really, really well. If you want a great example, go check out this billion dollar company. Still not impressed, why not check this site out as well. They are using the same PHP that you have. Need another… how about this site.

The reason this is the case is because PHP was designed to work hand in hand with Apache. The multi-process,+shared nothing architecture wins versus the multi-threaded+stateful dead-end that people continue to follow. I could go on about this (and I think I already did in an older blog post). In a nutshell, shared memory, long running multi-threaded instances end up with all sorts of nasty problems (scheduling issues, dead-locks, containment/failure-isolation, non-linear performance, etc.). The PHP architecture nudges the developer down a path that has the right balance of interface, logic, and persistence. PHP apps will not fail due to resource leakage or heap bloat that long running instances end up with. It isn’t the huge nightmare to hosting providers that other systems are. PHP apps will have a consistent and predictable performance profile. When they do fail (process limits, IO limits, database limits), you can generally just add more hardware at the right layer and scale up. Now, granted, scalability gets more complicated and we can get into queuing models and yada yada, but I think you get the point.

Compare that wiith every other web-app platform that trys to keep some multi-threaded instance running to handle requests (Rails, Java, and Python, etc.). They all have their issues. In fact, I would say that the #1 problem for rails is still that they don’t have a clean, simple, and scalable platform. Mongrel is still not the answer… it is just the best answer.

Another interesting point about PHP which has been true for as long as I can remember (which Terry brought up first). If you can think of an app, it has probably already been written in PHP. Why write a forum system if you can just get vBulletin? Why write your own Digg when there are 3 clones already out there? PHP has a tremendous supply of working code, ready to run.

That reminds me of another popular, high traffic site that everybody uses every day.

So, just to recap before people take this the wrong way:

  • I still love Ruby on Rails quite a bit. It was my first choice at BrightRoll and it was the right choice.
  • I think PHP is excellent at what it does, and would use it even now for simple projects.
  • PHP has issues and criticisms. However, I think the negatives and criticisms for other systems are larger for other systems (think Java or .NET)
  • All of the above still works even for not-so-hot developers. Don’t believe me, just look at the code for some popular PHP apps 🙂
  • I think all web developers should learn and understand PHP regardless of what they decide to use If you are choosing to ignore it then you may be going down the wrong path. Why would you want to do that?
  • ALSO, mad props to JackH for pointing out “I think there is something there with this PHP stuff”. His input got me to really look at that tech.
This entry was posted in General. Bookmark the permalink.

8 Responses to Thoughts on PHP

  1. I pretty much concur. Eric Rollins says that ‘C should be in the hindbrain of every coder’. I think in the same way PHP should be somewhere in the brain of every web programmer. Just because it truly hits the lowest of the low end of web scripting like no other language.

    A good example is when I have to mock up web service test pages. Say some customer has an XML page I need to get some data from. I know the format, but I can’t test against it for whatever reason. I can make a PHP page that does that format in about 0.5 milliseconds. Where any other language would take at least thirty minutes or more. Then I can push that page to a hosting site (all of which run PHP) and have a remote test in no time.

    BTW, here is another technical heads up. I’ve been playing around the WPF/E and it’s pretty sweet. I know it’s vendor specific, but it’s also cool. In addition, from Adobe, Flex 1 was a problem because of pricing and the server model. Flex 2 has fixed all that and is well worth the look.

    And before you say, “Yeah, ok, but not right for my current application”. I know that. I’m just giving you a little helpful info for tech developments that may be interesting for later projects.

  2. Enos Cummings says:

    I’ll jump in with my thumbs up on using PHP, too. But I’m curious, Dru, why despite the merits of PHP, you chose ROR (and seemingly do it again if you were to start all over). What’s different at BrightRoll that PHP doesn’t fit the bill?

  3. dru says:

    Jack: I wholeheartedly agree with you and Eric. I’ll check out WPF/E. Is there any SOAP or heavy XML-RPC stuff in there?

    Enos, or (should I say my old cube mate): Why ROR? The persistence automation and code generation really makes the default controller and view systems just work. In essence, you don’t have to write any SQL to get a real multi-user database driven application up.

  4. WPF/E is a lot lighter weight than you can imagine. It’s like Flash, but all of the scripting stuff is pushed back into the browsers Javascript mechanism. So you can do SOAP, or XML/RPC, to get data, just as you would with standard Ajax. Or you could use JSON or anything else you like.

    Unlike Flash, where browser integration is more like an afterthought, with WPF/E the browser is a critical component of the design. So you can take your DHTML skills and extend them with WPF/E.

  5. I don’t buy the scalability argument, at least not in the over-broad sense you’re using. I work in Python, and the same “shared nothing” architecture works just as well there, you’ve got mod_python and you can scale just as easily; you can slap load balancers out front, database pooling out back and just as many web nodes as you’d like in between.

    And if you need name-dropping: here’s a site which does a fair bit of traffic and is powered by Python.

    I don’t know Ruby or Rails as well as I know Python, but it seems like the same approach would work in pretty much any language.

  6. dru says:

    Hi James,

    I never said that other languages can’t do it the same way, so that is not my argument.

    What I said was that the PHP architecture nudges the developer down that path. Zope and all the old ‘right way to do it’ in python frameworks do not get the user down the right path.

    As far as Python and the web are concerned. I have been a user of Python since 1996 and know it well. Some of the sites I’ve worked on were based in Python. I wouldn’t use it for any future web projects unless the project was already done/built.

    Why? The language never had a good web framework. The need to cobble together packages and the lack of a Gems/CPAN like system has hurt Python IMHO. The final thing to consider is the whole whitespace syntax problem. It is hard to template with Python.

    Also, YouTube is a great site, but it is a simple site. They could have just as easily built it in Ruby.

  7. Harry Fuecks says:

    Just an aside – interesting to see that neko gives you the option to have it behave like php – http://nekovm.org/doc/modneko#scriptversus_application – unlike PHP it’s not really trying to be a runtime and a language – at least not for human to write in rather it’s meant to be generated.

  8. I think there are a lot of folks these days who’d disagree on the availability of good Python web frameworks; we now have an embarrassment of riches in that department (witness all the framework and web-dev talks at PyCon this year, for example).

    Templating’s a solved problem these days, too — there are template systems on all parts of the spectrum, from minimal or no “raw” code in the template to pure Python and everything in between. Maybe it’s time you had another look?

    As for YouTube being “simple”, well, it’s easy to be dismissive. WordPress is “just a blog”, and Wikipedia is “just a CMS with revision history”. And they are, but there’s a lot more to each of them than that — don’t be too quick to judge these sorts of things.

Leave a Reply

Your email address will not be published.