This past week I’ve spent some time evaluating CakePHP and trying to compare it to the things I’ve learned in Ruby on Rails. I checked out CakePHP over a year ago, and I admit I didn’t get into it as much as I had hoped. Having dealt with Struts while using Java, I felt at home with both in terms of their MVC nature and I have no desire to go back to life without a framework. Because CakePHP started out as a Rails Clone, they share many advantages:

• Convention over Configuration – Each framework tries to follow a set of standards in filenames, controller names, and so on so on. When I work on a site someone else designed using a framework, I know where things go and I can familiarize myself with that application much more quickly.
• Don’t Repeat Yourself – Specifying code in one place means that you only have to change it once should it need updating.
• MVC and a focus on “Fat Models” – Separate models, views, and controllers make life easier down the road when it comes time to switch to a new system that has a new database or when you want to make a fancy interface for an iPhone or the next new thing.

There are many other advantages to each, but let’s move on to the differences and disadvantages of these frameworks (keep in mind that this is from a somewhat unexperienced perspective, please let me know if these don’t convey the whole truth):

• CakePHP isn’t as mature as Ruby on Rails. Migrations aren’t fully integrated and the feature set seems to be a few steps behind Rails.
• CakePHP isn’t as easy to deploy as Ruby on Rails. This might matter more for larger applications, but I haven’t seen anything like Capistrano in Rails.
• Documentation is somewhat lacking in both. I had a hard time getting going using only tutorials that I found online. Rails has some great books, but I haven’t found any for CakePHP (although the tutorials and my familiarity with PHP made things easier).
• Ruby is new to me. In my opinion, it has a higher learning curve than PHP (possibly because I already knew Java before learning PHP).
• There are far fewer hosting solutions that provide good Ruby on Rails support. Although it’s pretty easy to get both up and running (especially for the lucky users of Mac OS 10.5), good hosting is pricier for Rails applications.

With all that said, there’s no way I’d like to go back to plain old PHP for developing a website. Things have come a long way even in just the past year for both of these frameworks, so I hope to keep learning them both. In the meantime, though, I’m devoting more of my time to Ruby on Rails, simply because I’m actually finding it fun to code in Ruby (and the Ruby Quiz is something I wish my programming classes had been) while PHP never had me quite as excited.