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.