Now that grad school is over with, I’ve already felt the need to find a new challenge to tackle. As you might guess, I get bored very quickly. I’ve chosen to learn Ruby and Rails. I’ve attempted to tackle this challenge in the past but I’ve always ended up frustrated enough to quit. To celebrate the release of Rails 2.0, I figured I would try once again.
I’ve been working with Ruby and Rails 2.0 for the last two days, and I am already a convert. I’ve ported the existing development of my company’s Intranet application from PHP / CakePHP to Ruby / Rails in less than one day. That one day was the first day I worked with RoR, if that tells you anything.
There is currently a holy war surrounding PHP / CakePHP and Ruby on Rails. Having used PHP for eight years and CakePHP for one year I was basically in a mental bind. PHP is great and definitely does the job at hand, but at times it shows its hacked-together nature. One of the main differences between PHP and Ruby is that Ruby is truly an object oriented programming language while PHP is a scripting language. What does this mean? Basically, Ruby handles dealing with logical code elements in a much more refined, repeatable, and logical way.
For example, in CakePHP, an Object (say ‘User’) only lasts as long as it takes for the framework to conjure it from the database. From then on, you’re dealing with an elaborate array of specific information:
// Load User from the database
$user = $this->User->findById(121);// Set User's last login time
$user['User']['last_login'] = date('Y-m-d g:i:s');// Save User back to the database
$this->User->save($user);
In contrast, doing the same operation in RoR on a Ruby Object looks like this:
Which language looks more friendly and logical to you? Exactly.
- Load User from the database
user = User.find 121- Set User's last login time user.last_login = Time.now
- Save User back to the database user.save
CakePHP is a godsend to the PHP community, and anyone stuck on/with PHP should be using it for every single project they work on. It’s a miracle. That being said, it is a poor clone of Rails in many ways.
Most of CakePHP’s shortcomings are due to PHP itself. PHP is not object oriented, so the CakePHP developers are coding with their hands tied from the start. Another major detraction from the framework is the severe lack of documentation. CakePHP 1.1 (the recommended stable version) does have a fair amount of documentation and an API available, but the latest and greatest version 1.2 does not have any official ‘manual’.
To be fair, most of 1.1’s documentation can be extrapolated to 1.2; however the features that make 1.2 desirable are scarcely documented. Developers close to the project post blogs that are helpful but this is far from a ideal situation. And yes, I do understand that 1.2 is in heavy development. This point is also won by RoR for its wonderful built-in documentation system that makes generating documentation effortless.
RoR is more mature feeling with a robust set of tools and documentation. Ruby itself is amazingly powerful and has a huge plugin library available. Rails has built-in support for the Prototype and script.aculo.us libraries so designing towards ‘Web 2.0’ standards is a cinch. After failing many times to do anything meaningful with Ajax in CakePHP I have already created a CRUD UI for an important Object in my Intranet application. Keep in mind, again, that I started with RoR yesterday and more specifically with Ajax this morning.
There are many more points in which RoR beats Cake/PHP; a few that spring to my mind:
1. Unit testing is built-in (no external libraries are needed)
2. Creating a new application is as easy as running ‘rails project_name’
3. Built-in web server
4. Much more robust debugging and query tracing (great for finding bottlenecks!)
5. Plugin installation is a breeze
The bottom line? If you’re stuck with PHP for you projects, use CakePHP. It’s a miracle for PHP. If you are not stuck with PHP, give Ruby on Rails a whirl. It makes coding fun again and you’ll be amazed on how quickly you’ll pick it up. I’ll be using it for all of my upcoming projects.
Excellent article. I haven’t tried RoR yet, but i will give a try now.
Oof, I can tell you that writing PHP without using CakePHP is like pulling teeth after having seen RoR. My noobishness with Ruby makes writing applications a pain, and don’t even get me started with trying to deploy a Rails app and all the pain involved.
Your example is dead on though, PHP takes some acrobatics to wedge into a Rails framework. I wonder if abandoning PHP4 support for being solely PHP5 would help Cake out? The OO stuff seems to be a huge boon to RoR, as with ActiveRecord (which has been pretty awesome since I saw it in .NET years ago).
I am so glad you wrote this article. I myself have just been programming with rails for the better part of 3 months (been with ruby for over1 yr now), and have been struggling wondering if I made the right choice. I used to code in php, but it was just aggravating, with Rails I literally laugh when something happens so easily. Check out railscast.com and peepcode for some good vids. Enjoy.
Hey Matt,
Glad to see you’re using the Elixir theme :) Nice modifications.
I’ve been reading a few of your blog posts and thought to write you an email, but seeing as you don’t have any contact info up on the site I’ll leave a comment here.
The topic of Rails vs… or Framework vs. Framework has been out in the wild now for quite some time. Recently Rails is under the spotlight with Zed Shaw’s rant and all of the responses in its wake.
It was refreshing to read your post here on Cake PHP vs Rails. I’m not nearly as experienced as you, but I too started with PHP and then slowly evolved to other languages. I’m not really a programmer either, just a designer, but I do enjoy dabbling from time to time in the back end stuff.
I work right now for a Python house, we do all of our stuff in Django mostly. We all kind of, to be honest, really don’t like the Rails community but to be fair me and a colleague are going to develop a simple app sometime soon in Rails. The guy I am going to work with already ordered one of the top Rails books out there, can’t remember the name but the cover is like red lights movin fast on the freeway or something. Written by Oslo something maybe?
I digress, what I originally intended on commenting on was how much I enjoy reading your blog. So far I have been through a few of your recent posts and really like this one in particular. Nice job explaining the differences between the frameworks while remaining fair to the fact that PHP really isn’t an OOP language. I’m not too familiar with Rails, Python mostly, but it was interesting to see the way you contrasted the PHP object oriented way of doing things, and the Ruby way.
I’ll definitely adding you to my collection of RSS feeds. Look forward to seeing new content from you soon. Hopefully I’ll get to take a look at the apps you’re workin on too :) I’ll let you know how our Rails app goes as well. Congrats on the Masters, and thanks for rockin’ Elixir :)
Ahh it’s in your recent books. The Rails Way, by Obie Fernandez. Hah, I’m such a retard. Anyways, we ordered that book a few days ago so should get started on a nice Rails project soon :)
Btw, it would be cool to talk shop with you one of these days.
Michael
@Jeremiah: Yep, the biggest difference between the frameworks is simply the languages that they use. As we know, using an OO language is almost always easier than a scripting / procedural one ;)
@Taylor: It’s funny, I’ve laughed quite a few times coding RoR. I think I nearly cried though when I discovered the glory that is the :through association. That logically simplified my application port from PHP so drastically I was in love.
@Michael: Your theme rules. I happened across it just a week or so ago and downloaded it right away! As for ‘not liking’ the RoR community; don’t worry. Sometimes fanboys can be more irritating than normal. RoR is great, but it’s just another tool in the toolbox. (Even if it is the newest and shiniest one). Obie Fernandez’s The Rails Way is the best Rails book I’ve read and it will definitely give you guys a great start. I’ll add my email under the ‘About’ section; I thought I had put it there already ;)
To all, thanks for your comments!
http://www.youtube.com/watch?v=n1NVfDlU6yQ
http://www.youtube.com/watch?v=Ld919lziKgE
http://www.youtube.com/watch?v=GQXqWkWqnSw
@Saurabh: Those are great! I’ve never seen them!
Thanks!
I started in Ruby on Rails about 2 years ago and had to do a recent project in CakePHP [1]. To me, CakePHP felt backwards and that many things were 80% complete. Good enough to get something working but hard to finish. Like you said, this can be attributed to the differences between PHP and Ruby and also that CakePHP is trying to be PHP4 compatible, almost 4 years after PHP5 was released.
That said, CakePHP is a great thing for PHP. I see way to much PHP “hacked out” with no structure at all.
[1]: Doing PHP was a major hurdle, they wouldn’t even consider Ruby.
“PHP is not object oriented”?
PHP is object oriented! :-)
The actual problem is with PHP’s implementation of OOP.
So yes, PHP is object oriented, but there are people (including me) who would like to see an improvement in the OOP features. Personally seeing spaghetti code and pseudo OOP makes me ill. Stop with the spaghetti code already and really for a better OOP model in PHP. Seriously, coding procedurally or using pseudo-OOP is like trying to engineer a bridge with paper. OK, procedural programming was OK 20 years ago. Procedural programming Vs. OOP programming is like 17th century architecture Vs. 21st century architecture. Stop it.
http://www.objectorientedphp.com/
PHP’s OOP is strapped on as an afterthought, though I do applaud their efforts.
Sure, you can write classes that have methods and inheritance and such, but PHP’s built-in functions are almost totally procedural. In Ruby ‘nil’ in an object, as is the number 1, or “String”. That is true OOP.
PHP’s built-in functions operate on variables, not on objects. Meaning that when you call something like “substr($string, 3)”; that is 100% procedural. A true OOP way would have the substr() function as a method of a string object, i.e. ”$string.substr(3)”.
Again, PHP is moving in the right direction, but I’m afraid that it would take basically a full language re-write before it is truly OOP.
Of course, that’s just my $0.02 ;)