Close and Go BackBack to Viget

Top 5 Reasons PHP Developers Love Rails

Patrick Reagan
Patrick Reagan, Development Director, May 10, 2007 4

As Mark mentioned in his latest post, most of our previous applications have been built with PHP (including Squidoo).  Despite all our years of collective PHP experience, we made the decision to switch new development to Rails less than a year ago.  In that time, we’ve hosted a training session, attended a conference, connected with other developers in the community, and even had one of our top developers selected to speak at this year’s RailsConf

Admittedly, the switch wasn’t altogether painless; but, as I look back on the past 7 months and how far we’ve come, I’ve made notes about everything that Rails provides that has made our lives easier.  This isn’t an exhaustive list (what did you expect?); but, it does cover the top 5 from across the Development Lab here at Viget:

  1. ActiveRecord – Obviously a critical component of the Rails framework and something that the PHP world still seems to be lacking.  It’s clear which ORM library you’ll use when developing in Rails; but, there isn’t a clear choice when developing in PHP.  While the myriad PHP frameworks provide a multitude of choices, nothing is as developer-friendly as ActiveRecord.
  2. Test::Unit – Though we were new to Rails, we had been using Test-driven development practices even in our PHP applications.  The framework that we developed in house pulled in SimpleTest to handle all our model and controller tests; but, the integration wasn’t as nice as we would have liked.  With Test::Unit and its integration into Rails, writing and running tests became both easier and faster.  Through the use of fixtures and database transactions, we no longer felt the pain of writing mundane (and sometimes complex) set up and teardown methods for managing our test data.
  3. Mocking Libraries – When working in PHP, we found ourselves changing the behavior of our classes just to make them easier to test.  Though SimpleTest did provide mocking capabilities, libraries like Mocha and FlexMock, combined with the power of Ruby, let us mock out method calls deep inside our code – something that just wasn’t possible for us before the switch.
  4. Filters – I recently found myself maintaining an existing PHP application where I needed to add some complex permissions checking.  While the task took quite a while, it would have been easily solved in Rails through the use of filters.  The ability to remove duplication with before filters and clean up exception handling with around filters has been a huge productivity boost for us.
  5. Ruby – Last on the list – but it’s truly the cornerstone of the framework.  We did have some of the hurdles involved with learning a new language; but, the time we spent ramping up has been well worth it.  The syntax of Ruby is much more elegant and consistent – something that PHP has been sorely lacking for a long time (I hear it’s coming in PHP 6).

As we continue to push for using Rails for web application development, I feel confident that we’re giving our clients the best solution possible while decreasing the time it takes to bring their products to market.

Trackback: Top 5 - Group Writing Project Day 4 on 05/11 at 10:02 AM [...] efforts to Ruby on Rails. Now that the new year is upon us, I can safely say that we’ve reaped rewards from the switch. Though ramping up the development team (myself included) on a new technology was [...]----- [...] If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!The people who developed Squidoo bring you a small insight why they moved over to Rails from PHP. Top 5 Reasons PHP Developers Love Rails [...]----- [...] Top 5 Reasons PHP Developers Love Rails by Patrick Reagan [...]----- [...] Top 5 Reasons PHP Developers Love Rails [...]----- [...] Top 5 Reasons PHP Developers Love Rails by Patrick Reagan [...]-----
Nick Halstead said on 05/12 at 12:47 PM

I agree there is not yet a clear framework for PHP. Although I hope the massive effort that is going into the Zend Framework will result in a clear winner.

On that note, the Zend Framework includes a fantastic filters class which is easy to extend and very easy to use.

I agree PHP is still suffer from pre-PHP 4 decisions, and with a list of something like 3000+ functions consistency was never going to be easy.

I think you took a bold decision to move completely, I do not think Ruby/Rails is yet mature enough for large scale enterprise. PHP with Zend (Platform, Core, Framework, etc..) plus all the enterprise partners that now support it still makes PHP the easy decision IMHO.

Basil Vandegriend said on 05/13 at 09:54 AM

Interesting article! I’ve been wanting to take a look at Rails for a while, so its nice to hear from someone who took the plunge.

Check out my Problogger submission, which I think you’ll find relevant: Top Five Essential Practices for Developing Software

Patrick Reagan - Director, Application Development said on 05/13 at 03:09 PM

@Nick: Thanks for the update on ZF - when Mike Naberezny presented on the framework at last year’s DC PHP Conference, he indicated that it wasn’t designed as an application framework per se but rather a collection tools under the Zend banner.  Has this changed, or are other people creating useful frameworks with the tools Zend is providing?

As for enterprise-readyness, I don’t know that PHP is necessarily better suited than Rails.  On both sides of the fence, there are plenty of applications that seem to be scaling quite well.  From Digg and Flickr (PHP) to ChaCha and Twitter (Rails) the solution to scaling isn’t in the underlying implementation language, but the architectural decisions that are made. Both Eli and Cal have acknowledged this in the talks I’ve attended.

@Basil: Thanks for the link, it’s definitely relevant.  We have been using all the practices you mention for quite some time now with much success.  If you do decide to get your hands dirty with Rails (and I encourage you to do so), take a look at Capistrano to handle the “repeatable build and deploy” process.  With Mark’s help, we standardized all our Rails deployment processes and haven’t looked back. Since it isn’t a Rails-specific tool, we’re also looking at it to automate the deployment of our legacy PHP applications.

Coder said on 06/28 at 03:10 PM

Nothing compares to rails.

It’s such a convenience.

Thanks for sharing

Next entry: What's Coming in Rails 2.0

Previous entry: Being Conventional

We're the Developers

at Viget Labs. We write about web development trends, tips, best practices, industry events, and our projects — all with an emphasis on Ruby on Rails.

Recent Comments

Tony,

I understand and agree that the back-end shouldn’t output code (html code), and only content. The templates (aka views) should do the trick, but instead of having lot’s of if/else conditionals inside the view, you may just output the following content.

No information available

The template would loop in an array and put all the <li>’s inside the <ul>.
I don’t see anything wrong, nor...