On 9th Jan, ’10, I presented my topic “CakePHP Vs Rails” at PHPCamp. It was well received and it felt nice to have been able to present such a topic to PHP devs. I was expecting a ‘fight’ (infact quite a few people did too) but I did keep the tempo low and to a discussion and not a debate – expect the unexpected !
Having said this, the controversy started long before my talk though – right from the choice of the title. My opinion is that almost 90% of PHP development is web-development, so the topic – ‘PHP Vs Ruby On Rails’ was on the button. However, Amit Singh, Dhananjay Nene disagreed – they felt it was comparing apples to oranges. I complied to their request and changed the title – Fair enough. BUT how do you explain that there were 2 hands raised in a room of about 80, who said that they used PHP earlier for non web-development ;). All in all, I did finally compare Ruby with PHP and CakePHP with Rails.
PHPcamp had 2000+ registrants and the venue was ‘packed’ – it was very exciting to go a PHPcamp as a rubyist. I wondered if people sensed a wolf among the sheep (couldn’t resist that taunt, 😉 my apologies ) and when I went up to the wikiwall to note my topic, I did get a few curt nods and some smiles and a Ah-you-are-the-rails-guy looks!
I kept my talk after Aditya’s talk on ‘Introduction to CakePHP’ because it would help my cause for people to know more about CakePHP when I compared it with Rails. The talk was really good — and I could see a lot of my effort reducing in explaining MVC, RESTfulness, relationships etc. the rails way. The slides are posted here.
Before I did a deep-dive, I wanted to grasp the type of audience I was dealing with and realized a decent mix of professionals, students and even a few entrepreneurs. I decided to keep my talk a little less-technical, should people sleep off ;).
I started with a brief comparison of PHP and Ruby. The Pure OO Ruby, mention of blocks and meta-programing. The idea of blocks of code being sent as parameters to methods and the idea of defining a method on an object seemed to have intrigued the crowd — however, given that I had to keep the talk basic and not too technical, I am sure it did go a little over the top. Never mind – at least I had got everyone’s attention. In a lighter moment, I did mention the use of throwing shoes as opposed to rotten tomatoes if required. I did not have the pleasure of getting as famous as famous presidents as nobody lost any shoes !
I then gave a brief comparison of CakePHP and Rails which brought me to the main discussion. CakePHP has a directory structure similar to rails and I believe it has been modeled around Rails (at least in the beginning). The model based relationships are similar to Rails, except for HasAndBelongsToMany. In Rails it has been changed to has_many :through => relationship. I particularly liked the ‘on the fly’ binding in CakePHP – its pretty cool. In rails this is achieved by a little bit of meta-programing and adding class methods to the model to load new functionality.
Both frameworks preach being model-heavy which is excellent. However I was a little surprised with Aditya mentioning that scaffolding should not be used extensively. I do believe that the RESTful code generators in Rails are excellent and scaffolding should be used extensively to get a jump-start.
RESTfulness was skimmed through the CakePHP talk but I re-iterated in my talk the importance of inherent RESTfulness that helps in interoperability. I could see a heads nodding when I used an example of user account creation URL — got plenty of answers, /add_user, /create_users, etc. and the look of enlightenment when I explained how HTTP verbs are used to ensure that /users (with GET) will get the list of users and /users (with POST) will create a user.
There was finally a person who raised the question of speed and performance in pure PHP code Vs Ruby Code. Now, it is indeed undeniable that PHP code interprets faster then Ruby, in fact as the gentleman said – “The 10 lines of PHP code will run faster than the 3 line of similar Ruby code”. Agreed!
I was filled with pride that he mentioned the really cool part of Ruby coding — LESS CODE, which in turn means less bugs. (Yes – I know there will be a lot of PHP enthusiasts who will flame me for this — but it is a fact!). Ok – back to the speed and performance issue — in my opinion, CakePHP would run much slower than Rails (courtesy internal caching). However, pure PHP code would run a tad faster than Rails. This is definitely debatable but I would forgo some performance and speed in favour of lesser lines of code. In addition to this, the ruby interpreters (MRI and Jruby) are reaching epic proportions of speed in interpreting.
I then moved onto what I found missing (or lacking) in CakePHP as opposed to Rails.
- The one thing that stands out is the use of migrations. I was shocked to see event the examples on the dev site, showing SQL file for creating and updating the database.
- The lack of deployment information was understandable (standard Apache with mod_php I guess) but I think this is lacking. Capistrano is something I did not mention in the talk but its things like this that make deployment simple! I was talking to some of the experts later, Amit, Aditya and Shardul after the talk and they told me that most still rely on scp and ftp for production deployment! I hope that is incorrect, but was a little taken aback never-the-less.
- There does not seem to be much information about the use of caching in CakePHP — it seemed to be more out of the do-it-yourself manual via memcached. Rails internal caching is superb – object caching, query caching and fragment caching really get things going. Though I found information about caching in CakePHP, I wonder how much people use it.
- The Rails magic of instance variables in controllers directly being accessible in views is cool. CakePHP requires the use of set() to ensure this. Decent enough though lot of scope of mistakes, IMO.
- Routing and RESTful routing seemed a little behind compared to rails. Aditya did mention that default RESTful routes are now available in CakePHP but from the documentation and usage it seemed lacking. I love the following routing in Rails which gives me all the RESTful CRUD automagically.
To conclude, the fact is that CakePHP makes life unbelievably happier for PHP web development – I would call it a boon! I personally do see a lot of similarity between CakePHP and Rails – in fact I did tweet that that what Rails does, CakePHP follows. However, surprisingly, Larry E. Masters disagreed with me. His opinion is very important in the context as he is the Co-founder of CakePHP! Check out his interesting replies to my tweet here and here Now, that is spunk and attitude ideal for competitive development – Its highly appreciated as it will make things better! I would like to ‘twibate’ on it sometime, but I think that would digress from this topic 🙂
All in all, I say to PHP devs, — Try the real thing!