Notes on Rails vs. PHP

Sometime in the late 90s, a co-worker at Ziff showed me how he could build a web browser in Visual Basic in five minutes flat. Sure, it was a sucky browser, but it worked, and the feat was impressive. It was my first exposure to the power of RAD (rapid application development), and the advantages of using a higher-level development platform that takes care of arcane plumbing for you.

Fast-forward eight years. Reading up on Rails and preparing to unleash RoR on Birdhouse (no, not quite ready yet), has gotten me thinking about the advantages of one web application development framework over another, as opposed to the advantages of one language over another.

Ruby is a graceful language — as clean as they come. But getting up to speed with it is still going to consume dozens (or hundreds) of hours I don’t have to give. PHP may not be as clean as Ruby, but it’s also a great language — easy to start working in quickly, easy to improve your skills incrementally. It’s an extremely productive environment. In many ways, PHP is succeeding through its simplicity and great productivity curve in places formerly reserved for Java. And hard-core Java programmers who have regarded PHP as a “toy” language are being forced to re-think that position.

Over the past five years I’ve put hundreds of hours into learning and applying PHP in the real world. It began to dawn on me that what I’m really lusting after is not so much Ruby itself, but the Rails RAD framework. Surely there must be some equivalent of Rails that sits on top of PHP? Enter the fragmentation problem so common in the open source world. Rather than centering on a single MVC framework as Ruby has done with Rails, at least a dozen different framework projects are out there for PHP, none of them regarded as the standard. Projects like Seagull and Phrame and Yellow Duck all seem to be trying to skin the same cat. Smarty, which is an official offshoot of PHP itself, bills itself as a framework, but really seems to focus on being a killer templating engine (we’re using Smarty for the coming J-School site redesign). Zend’s collaboration with IBM and others on a full RAD framework for PHP probably holds the most promise of providing a unified standard, but who knows how far away it is from release, let alone maturity.

The fragmentation and uncertainty surrounding PHP framework standards means adopting one now is risky. No one wants to write thousands of lines of code on top of a platform that may become marginalized when the world coalesces behind something else in the future. Ye olde data lock-in problem, extended to the code level.

Meanwhile, not every review of Rails development is unequivocally glowing. This post on Rails vs. PHP references a common complaint about Rails: Once you get beyond the scaffolding stage, the ease-of-development advantage diminishes quickly. And debugging a Rails application can be a lot trickier than dealing with simple PHP objects and pages, since code gets so abstracted from the core language below.

For now, I think I’m going to see how far I can push Smarty. Its compatibility with my existing PHP experience and codebase make it a natural choice for framework exploration. Rails may have to wait for some fresh project on the horizon. Looking forward to it, but not sure there’s enough pay-off to warrant dropping everything and jumping ship.

Music: The Vines :: 1969

11 Replies to “Notes on Rails vs. PHP”

  1. So, in my copious free time, I’m the release engineer for EIRS (the Election Incident Reporting System)… and we’ve done quite a bit with php and smarty… especially in terms of modularizing codes with nested templates and such… check out the current HEAD here:

    http://dev.voteprotect.org/dev/HEAD/eirs/html/eir/

    (click Maps/Research to see some of the non-login stuff)

    However, debugging nasty bugs can really mess with your head… so many objects, SQL calls, smarty logic… yikes.

  2. PHP vs Java: A company that I was recently involved with is building a new web project with Oracle, J2EE, and Solaris servers. To me, this was a dead giveaway that they had fallen for the lure of expensive, over-engineered products when stable, inexpensive alternatives (MySQL, PHP, and Linux/Apache servers) are widely available, well-understood, and well-supported. I mean, the web is not rocket science. Pretty good trumps perfect every time, if pretty good is orders of magnitude cheaper and faster than the “perfect” alternative.

  3. So what do you recommend as a resource for learning PHP ? I’ve seen some O’Reilly books, which I generally like, but not all of them appear to cover the latest version.

  4. For learning, I’m not sure you need to be too concerned with the very latest version. 99% of the stuff you’ll need in the learning stage is already in PHP 4, and you can later pick up any more recent details online.

    For the dry / reference stuff, a nice combination are O’Reilly’s “PHP Cookbook” and “Programming PHP.”

    I honestly don’t recall the title of the first PHP book I got – it’s on my shelf at work – but it’s probably way out of date by now. I really think you can get up to speed just fine using online tutorials. Lots of good stuff listed here:

    http://www.php.net/support.php

  5. Scot, you might get a kick out of Code Stylist IDE — it’s a pure-PHP metaprogramming utility with MVC and a very fast learning curve.

    Today the 1.0.2 version is posted with many fewer bugs :-p — I used Code Stylist to win the Race to Linux and am open to all ideas about architecture and how to make it fast and secure.

    I’m preparing a demo movie with AJAX examples via Dojo Toolkit for release in the next day or two.

    -brian

Leave a Reply

Your email address will not be published.