CakePHP vs. Ruby On Rails – A Very Bias Look at Why I Choose CakePHP

First of let me state that this post is very bias towards CakePHP. Truth be told, I haven’t even installed or used Ruby on Rails. The closest I’ve come is looking at various code snippets I’ve found around. With that said, you may want to stop reading now.

These arguments are not based on hard facts, since I haven’t done much research on the matter. A lot of them come from a post at Clickable Bliss discussing the PHP vs. Ruby On Rails Issue.

  1. Steep Learning Curve – Laziness

    One thing I really hate is learning stuff. It is especially bothersome when you’re trying to crank out a project or web application in a limited amount of time.

    With CakePHP I’m required to learn about the MVC style of development as well as CakePHP conventions.

    With Ruby on Rails, I would have to learn MVC, Ruby on Rails conventions and I would have to start from scratch with the Ruby programming language as well.

    A lot of developers adopt the Programming Is Programming philosophy. They say that coding concepts are standard across the board; You’ve seen one language, you’ve seem em’ all!

    That may be true in general, but there was no way I was going to learn an entirely new language on the eve of project development. I’ve been meddling with PHP on and off for years now, so I feel more comfortable in the environment.

  2. Setup and Deployment – More Laziness

    With CakePHP, I know I could boot up my PC download and install WAMP and be done with it. If I wasn’t home and only had my USB Disk, XAMPP Lite would serve just as well. I dump the CakePHP code into a folder, tweak my config file and I’m good to go.

    With RoR, the preferred method is downloading and installing Ruby, then installing MySQL, then installing Rails, then configuring with your web server (if you have one). You could also go the LAMP route with InstantRails, but this is less flexible.

    Deploying to customers is usually a breeze. Change the config file to point to a different database, maybe change some .htaccess files, then copy and paste. It doesn’t get much simpler. With RoR, who knows what’s involved?

  3. Shared Host Support – I’m Just Cheap Like That

    This, by far, was my major turn off to Ruby On Rails. When it first hit the scene, none of the hosts that I used supported RoR. Back in the day, you would need a dedicated server to use RoR effectively.

    This wasn’t going to fly for me. I don’t do Web Development for my health or for fun. I design web applications for clients. A lot of my work involves redesign of already existing sites. How do I say to a client: Hey, although your current web host that you’ve prepaid a year for is sufficient for 90% or the stuff you can throw at it, I’m using this new technology and you need to shell out some more $$$ for a host that can handle it.

    PHP hosts are a dime a dozen. 98% (again not a hard fact, but an educated guess) of hosts that you pay for will offer at least PHP 4. Although more and more shared hosts, like Dreamhost, are supporting Ruby on Rails, they were quite scarce back when I had to make my choice of frameworks.

  4. Speed

    This is going to be a touchy subject. But let me just blurt out what I’ve read: Ruby on Rails is inherently slow. There, I said it. It’s not its fault, it was created that way by design.

    Because everything in RoR is an object, it has to be instantiated, which takes up CPU time and memory. Even empty objects. With PHP and empty array is a memory address, that’s it. Although CakePHP does support OOP using PHP5, most of CakePHP’s data manipulation is still heavily array based.

    There are steps you can take to speed up RoR. Running it using Fast CGI is one option. But again we get to the point of what is a available on shared hosts. Even on dedicated hosts performance is a problem. The RoR community has taken the Throw More Hardware At It defense, but everyone doesn’t have that options. They are quite vested in Moore’s Law, which basically states that hardware performance will continue to increase exponentially, due to increases in technology.

    Even one of the developers of Twitter (huge RoR application) has expressed concern about RoR’s performance. For the rest of us of us on shared hosts or who write small/medium sized applications for clients on shared hosts, Fast CGI (if not already installed) and adding a faster CPU are luxuries that we simply do not have. I would also remind you that even Mr. Moore himself stated that the law “can’t continue forever”. There’s going to be a point when things get down the atomic sizes, then what? But anyway, that’s a whole other discussion.

    My point is, I write efficient code when I can. Other times I write “get it done” code. I can’t afford to my framework to slow me down even more than I’m going slow down myself. With these memory and CPU issues, I even wonder how shared hosts are able to provide RoR services to all their customers.

  5. Object Oriented Programming

    Rails is all about OOP, from head to toe. Most times, that’s a good thing.

    There’s not much to say about this in CakePHP’s defense. Because the decision was made to support PHP4, the full power of OOP cannot be exploited. However, there are a few things to keep in mind. PHP4 development is officially dead, PHP6 is around the corner, and CakePHP is still at version 1. The future holds exponential growth for CakePHP.

    Me personally, I don’t really care. CakePHP gets the job done for me, that’s all I ask.

  6. Documentation

    Fair is fair. Here, I concede. Rails has some great online documentation and even a great book out there.

    The CakePHP community lacks documentation in a major way. One of the major reasons for this is that the project is still growing so rapidly that documentation would actually hurt for two reasons: It would slow down the developers and in five (5) months it might be obsolete. Right now, we are left to hunt and peck through the API to determine how to do things or ask around in the CakePHP Group.

    As development slows down a big, the documentation will evolve. I’m gonna go out on a limb here and predict that by CakePHP 1.5, we should have some solid documentation out there. By version 2.0 we should have a book.

It’s important to note that when it comes to decisions like these, I am in no way loyal (Sorry guys). I usually vote for whatever is going to create less work for me. So far, CakePHP has been leading the forefront in “Making Less Work For Baz” so it’s two thumbs up.

Comments

  1. Vishwa Rao says:

    Ben, Remi
    Thank you. I am convinced about Ruby/RoR. I will learn and implement it.

  2. Most of these points are correct.
    1. More developers know PHP, so this also makes it easier to recruit. However, if you want to keep your job then RoR prevents others from getting it as easily.
    2. RoR takes awhile long to setup (at least for me). CakePHP’s Bake system seems to be much better at setting up a website.
    3. Yes, there are billions of hosts for PHP but very little for RoR.
    4. RoR isn’t that slow, but Ruby is known for slow speeds which gets noticeable in RoR. The new 1.9 release with YARV should speeds things up, but PHP is still much faster.
    5. Who cares about OOP? I prefer speed over ease of programming. I mean, I like OOP, but I can sacrifice it.
    6. At the moment CakePHP’s documentation is a lot better then it used to be.

  3. Luiji… for your points

    1) more “inexperienced” programmer know PHP. Better programmers and experienced developers can and will learn a new language with ease.

    2) Rails is piss easy to setup. Migrations are a LOT more efficient and easier to use than Cake’s Bake!

    3) There are servers called “Dedicated” which, when writing professional applications is generally the prefered choice for the client….you get what you pay for. Shared hosting is simply nonsense for anything more than a personal blog of personal home page.

    4) Rails is pretty damn fast when you KNOW how to optimise it and write good maintainable effiecient code.

    5) I do!!!! Have you ever worked on a system with over 100’000 lines of code in PHP? I have and PHP = nightmare to maintain which in turn = a LOT more time finding bugs, adding changes and of course not to mention, cakePHP with its lack of a proper testing framework (where rails excels) imakes for a pretty horrid time at work.

    6) Ruby doc is fantastic…Ruby has been around for as long as PHP…Rails is a fantastic framework. Easy to learn, easy to setup and easy to deploy applications. Easy to maintain, easy to share amongst other developers, easier….you get the message.

    Unless you have worked professionally using Rails I’d keep your opinion to yourself. I have worked with both frameworks and currently the company I work for is binning PHP altogether and switching entirely to Rails and so far the results are a heck of a lot better than what we could do with PHP.

    PHP is a hack language. No proper convention, not even a proper OOP language. No closures, blocks and the testing frameworks are a complete pain in the ass.

    Speed….hmmm…what a stupid argument!

    http://highscalability.com/friends-sale-architecture-300-million-page-view-month-facebook-ror-app

    • === Disagreements ===

      First: speed is a stupid argument? SPEED IS ONE OF THE MOST IMPORTANT FACTORS OF AN APPLICATION!!!

      Ruby doc may be “fantastic”, however I learned the ins and outs of CakePHP programming in a week, and I’ve been using rails for a year.

      It took me half an hour to set up my first Rails application, and three minutes for my first CakePHP application. The fact of the matter is that Rails doesn’t work out of the box (no matter how much they say it does).

      There are a huge number of developers that prefer procedural over OOP. Why do you think that C is so popular? (Not that I like C.) I personally love OOP, but I’m willing to sacrifice it. With the modular architectures of both frameworks, including MVP and Convention Over Configuration, management is actually quite easy without OOP.

      “PHP is a hack language.” Not sure what that means…do you mean it’s generally a bad language? That’s a huge matter of opinion. Both closures and blocks are in PHP as far as I can tell.

      === Agreements ===

      You corrected me on the speed information.

      I haven’t done much in testing, but it seems that Rails does have an easier testing framework.

      === Finally ===

      “Unless you have worked professionally using Rails”. I have.

      I am not trying to say CakePHP is better then RoR. The arguments I had listed were just to explain why I personally like CakePHP more. I believe that each is better for different purposes.

  4. @luijii…. did you even take time to read the link I provided! SPEED is irrelevant when it comes to Rails as rails is, believe it or not VERY fast when you write good code….

    ….read the article I posted. 300 million page views per month and they have very goos response time and server side processing.

    READ READ READ!!!!

    When will we ever hear the end of the “rails is slow” crap…seriously!

  5. C is fast…. it is old, it is what most OS’s are written on. C++ is basically what is used for most modern embeded software…why?

    Rails out of the box? hmmm…how long does it take to write very basic UNIX commands in a shell? Well yea thats how long it took for me to setup Rails. How long does it take to deploy a rails app straight from repo? Again… two words my friend “cap deploy”…not only that I can deploy to several different servers at ONCE using the same command.

    PHP is good for certain things but for something large it is simply not worth the hassle working with it. We write our binary processors in PHP NOT Ruby, we write our logging system in C…why? because its fast….we write our portals and applications in ruby and use the rails framework simply because its GOOD!

    What is your professional expeirence with Ruby? I highly doubt its been much from what I’ve gathered…

    …look I cant be arsed talking crap about which is best or whatever…we use them all and for web applications nothing really touches the development speed of Rails…as for scalability…read that article.

  6. closures in PHP… I’m afraid not… maybe hacked up implementations but nothing like the real thing…. why would you use a closure? what about a block? what use are blocks…again PHP just doesnt have blocks? What about metaprogramming in PHP….hmm….

    rant over.

    PHP = ad-hoc language usefull for making a mess and maintenance nightmares

    • @Luiji @DT

      DT: I agree with most of what you’re saying, but Luiji was merely pointing out why he prefers CakePHP.

      Luiji: Sacrificing OOP is only acceptable within the scope of a framework that allows you to encapsulate code via some other means … which is very much like using OOP. Without this, you cannot create a maintainable codebase. You need to be able to write DRY, easily maintainable code.

      Both DT & Luiji: Your arguments about speed are nil, in my opinion, because you haven’t done the research to discover that Rails is faster than the popular PHP frameworks, eg. CodeIgniter and CakePHP [1]. While PHP generally performs faster than Ruby, Ruby web frameworks *greatly* outperform PHP ones, in general. I think this is because Ruby is optimized to work with lots and lots of objects in memory, whereas OOP has been added to PHP and it’s not nearly as optimized.

      Also, PHP is like CGI in that you typically load the *ENTIRE* environment into memory for each request, which is a very old-school way of doing web development. Most modern web development frameworks (Ruby/Python/.NET/Java) load the application into memory once, instead of on each request. This greatly improves response times.

      Ruby also has the advantage of having numerous implementations. JRuby is very mature and might be the fastest Ruby VM for running Rails 3 [2]. MacRuby is becoming a big contender, as well. Ofcourse, a side benefit of all of Ruby’s implementations is that you can access very fast, mature .NET/Java/Objective-C (and more) libraries from Ruby, as well as standard C libraries.

      Regarding deployment, PHP can be deployed just as easily as Rails and many PHP shops favor Capistrano for deployment! One doesn’t have any advantage over the other. There are also good free & cheap hosts for both PHP and Rails.

      Testing. This is the number 1 reason why I dislike coding PHP nowadays. I have written lots of PHP over the years and I’ve written PHP code as recently as a few months ago. Ruby has MUCH better testing tools. This is really unfortunate because it creates a barrier to entry for PHP developers to start testing and test-driving their code.

      Regardless of the programming language or the framework you use, testing is the #1 most important thing for delivering quality, bug-free, maintainable software!

      [1]: http://merbist.com/wp-content/uploads/2008/11/benchmarks.png
      [2]: http://www.engineyard.com/blog/2009/rails-and-merb-merge-performance-part-2-of-6/

    • After reading the article which you linked to (of which I didn’t notice before) along with related articles, I’ve come to a conclusion which is essentially a restatement of one of yours.

      CakePHP is good for small projects such as blogs and forums, Rails is great for huge projects such as Twitter, Amazon, and Facebook.

      • Luiji. Saying Rails isn’t good for a smaller project is just plain non-sense. Earlier you stated writing Cake apps was quicker because of cake bake. If you took the time to learn about the actual rails command, you’d know that cake bake is simply a cheap version of the rails command.

        CakePHP was developed as a PHP port of Rails. All this easy stuff on Cake is pretty much the same on Rails (just in ruby). Don’t be lazy, learn it! Ruby is a lot easier than PHP. What takes 100 lines in PHP will take probably 25-30 lines in ruby.

        • Wow, I forgot about this long ago.

          I haven’t done much web programming in awhile. As far as I can tell, MRI’s integration of YARV’s going to solve most of RoR’s problems. I’m using it next time I code a web app.

          Also, I’m not lazy, just at the time I had very little skill at finding the right documentation. Now I’m pretty good at it.

          I’d rather not continue this subject, as I’m not much interested in it any more.

          Happy coding!

Trackbacks

  1. […] Dominican developer Kevin Lloyd has written a succinct list of the reasons to choose CakePHP over RoR: […]