PHPcamp – CakePHP Vs Ruby On Rails

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.
  • map.resources :users
  • Polymorphic associations were missing (but I may be wrong here — I am sure its supported).

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!

8 thoughts on “PHPcamp – CakePHP Vs Ruby On Rails

  1. Wow… it was a nice session i was there :)… as i have a knowledge of Ruby (little bit) and a PHP more 🙂 .. Even though i am a PHPian still i wanted to work on RoR and thats why i learned RoR on my own and i fall in love with ruby .. but unfortunately i haven’t got a chance to work on it .. all in all its gr8 language to work with .. Hope i will get a chance to work on it .. PHP is also a gr8 language as i work on it 😀 .. OOPS concept was brought in late release thats why it has some limitations .. but the frameworks like Symfony and cakePHP gives the feel like working in OOPS language .. Thanks for your session it was mind blowing

  2. In your blog statement you stated, “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!”, this may have been true in the past but I don’t feel that this is true today with these Ruby implementations: Ruby 1.8.7, Ruby 1.9.1, Ruby 1.9.2, MacRuby, Maglev, Rubinius, IronRuby, JRuby, and others Ruby VMs.

    Now, I’m not saying that PHP is bad but the myth about Ruby is true anymore. Thus, it might have been good to take a simple example like sorting and write it in both PHP and Ruby which
    can demonstrated to the attendees.

    Recently, I went to an interview with a PHP shop and one person said something to the fact that Ruby has some performance problems. Thus, I took out my laptop (i.e. MacBook Pro 3.06 Ghz Intel Core 2 Duo, and 8GB RAM) and displayed the merge-sort algorithm implemented in both Ruby and PHP. BTW, this algorithm takes two identical sets consisting of 100 integers each and sorts them 3000 times. Then I ran the time tested Ruby code using Ruby 1.9.1. Next, I ran the time tested PHP code using the PHP 5.3.1. Ruby 1.9.1 was about 3.15X faster than PHP 5.3.1 being able to complete this task in under 2 seconds. Finally, it was clear that this myth wasn’t true.

  3. I have worked on both Cake & RoR. One thing thats lacking in RoR is – you cannot have multiple apps in one folder (without doing harakiri)

    where as in cakephp, you can have any no. of apps inside a single cakephp installation folder.
    In RoR, its
    /rorapps/
    /app/
    /public/

    where as:
    /cakephproot/
    /app1/

    /app/webroot
    /app2/

    /app2/webroot
    /app3/

    /app3/webroot

    Other than that – I found developers quite plenty in PHP, where as RoR were in few (and the ones were good !!)

    1. @Rajesh In addition to allowing someone to configure multiple applications at the web server level as Gautam points out, one can add/create one or more Rack application(s) that sit between the web server and the application code. For example, here’s a simple Rack application that sets the “X-Runtime” header with the elapsed time of the request:

      
      module Rack
        # Sets an "X-Runtime" response header, indicating the response
        # time of the request, in seconds
        #
        # You can put it right before the application to see the processing
        # time, or before all the other middlewares to include time for them,
        # too.
        class Runtime
          def initialize(app, name = nil)
            @app = app
            @header_name = "X-Runtime"
            @header_name << "-#{name}" if name
          end
      
          def call(env)
            start_time = Time.now
            status, headers, body = @app.call(env)
            request_time = Time.now - start_time
      
            if !headers.has_key?(@header_name)
              headers[@header_name] = "%0.6f" % request_time
            end
      
            [status, headers, body]
          end
        end
      end
      
      
  4. Hmmmm…I know its quite late @ commenting on the Pune PHPCamp…but I actually found ur blog by mistake (searching for PHPCamp pics…couldnt find it 😦 )…couldnt resist commenting 😀 .
    Every topic I attended @ the camp had something to do within PHP or rather in support of it…..yours was the only 1 which had a hidden agenda of diverting the PHP followers into RoR ! How were you allowed 2 infiltrate into the camp ???

    But seriously yours was the most interesting discussion….you were so much at ease interacting with the audience..& it showed. Plz keep up your good work 🙂

    1. @Rohit LoL — it was an innocent attempt to compare 2 web frameworks 😉

      On a serious note, I was really happy to be well received at PHPcamp, it shows the power of “openness” in opensource! Thank you for your kind words.

      There was no hidden agenda 😉 ref: ‘Art of War – Shun Tzu’

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.