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.


  1. I have seriously learned ROR and stated to develop a website using it last year. But the real problem comes when I started to host the site on my shared hosting. Finally I give it up because I as well as my client was not so patient.

  2. Right now the number of hosts that allow Ruby on Rails has increased dramatically. You shouldn’t have any problems right now. This post listed my reasons “at the time”. Currently, I’m trying to move from small client based projects to bigger budget projects. With these, there is no “existing host” to bother about, so I have more flexibility.

  3. “And who the hell like slow applications anyway.”

    I love it when people assume that, because it’s written in PHP, CakePHP is faster than Ruby on Rails.

    PHP is faster than Ruby. A *lot* faster.
    Ruby on Rails is faster than CakePHP. About 15x.

    Ruby is created to be dynamic – to be changed on the fly. Ruby is much faster when it comes to meta-programming and the like (the things that make Rails and CakePHP possible). PHP’s fibonacci sequence, on the other hand, is *way* faster than Ruby’s … for all the times you find yourself needing to do that!

    I used to adore PHP so I’m not an outsider here, but I’m a Ruby on Rails professional now. For web application development, I find Ruby on Rails to be more productive than anything I’ve used but there are many great alternatives, like CakePHP. If it weren’t for the fact that I *love* Ruby (and RoR has a significantly larger community and is faster and whatnot), I would be just as happy to code in a framework build in PHP or Python or something.

    Good points in the post – using something that you already know the language for is ideal! Anyone who’s interested, however … from the perspective of an ex-PHP coder … I love Rails and it’s worth trying out. There’s a LOT of demand for it right now, too.

  4. One more thing! The reason people run into deployment issues with Rails is because Rails is nearly always deployed using an application server, just like .NET/Java … and I’m fairly certain that you can run a PHP application server too? Maybe not. Anyway, this is for performance.

    Basically, when you use an application server, it loads up your application into memory so, whenever a user hits your site, the application is already loaded and can respond quickly. Typically, PHP isn’t done like that – each hit requires the full application to be loaded. Someone correct me if I’m wrong – there might be some caching that mod_php does but, basically, the whole app gets loaded once per request.

    Typically, “the whole app” means a single PHP script for PHP, but for something like CakePHP or Rails, there’s way more than that … the environment might include the routes, the database connection objects, the template rendering engine(s) … all kinds of stuff.

    Rails *CAN* be run on a shared host perfectly well using any kind of *CGI, loading the full environment per request … but this is very slow, which is why ruby web frameworks typically use application servers, so everything’s loaded up and can be *very* fast.

    Luckily, for anyone interested in Rails development, there’s an Apache module (“mod_rails”) that can run ruby web frameworks, including Rails, and some shared hosts let you use this 🙂 You might have to pay extra or upgrade your account on some hosts for this functionality, because of the memory usage, unfortunately. That’s why it’s conventional for Rails developers to run their apps on their “own” servers (VPSes).

    [/ rails deployment rant ]

  5. Dude, I read the hole post. That was really interesting : your point of view is honest and I appreciated that. You almost made me loose my cusiosity about Ruby. To me, main cons are :

    – Less speed, more expenses. If I purchase an expensive dedicated server to support the technology, it shouldn’t be slow. If I buy cheap hosting for php, it will be ok. If I purchase a dedicated host for php… It should be very fast!
    – Pain of learning a new language. I admit I love to learn, but this is true that php is such a great language I could not avoid while building a web application.

    So I go into your sense, even though RoR looks smart.

    Ben’s last blog post..“Nous avons été visités” affirme un astronaute célèbre

  6. I believe people should use the tools they love. If you love PHP, you should use it (assuming it makes sense for the project). The same goes for Ruby and any other language out there … if you love the tool and it works for your particular project, use it!

    That said, it’s simply untrue to say that “Ruby on Rails is inherently slow” … RoR is **faster** than CakePHP. That’s not to say that CakePHP isn’t any good or that Rails is the best … but the fact remains: Rails is faster.

    If you’re looking for a hackers web framework and you’re not quite satisfied with Rails, I would look into Merb. It’s simpler than Rails and much faster, too (*WAY* faster than CakePHP & CodeIgniter).

    • I really need to update this post. 🙂 Since then, I have actually started Ruby on Rails and love it. It just so happens that most of my current work is still in PHP, but I’d love to be able to transition more fluidly to RoR. I just don’t have many projects that require it right now.

  7. actually, rails is a *LOT* faster than CakePHP

  8. Hi all,
    This discussion was very informative. Thank you, but I still find it hard to make a decision. Here is my situation. I have worked with php for a few years now and I feel comfortable with it but I have no problem learning another language as long as there is a strong community behind it. I am not limited by a client so I get to choose which ever one I prefer. I am not tightened by a deadline and I need a performance screamer framework. I am also looking for a framework that will integrate well with other open source projects like drupal (CMS) and phpBB (Discussion Board Forums) because I believe, correct if I am wrong, neither framework is mature enough to build CMSes or forums as stable and flexible as what is already available in the community.

    Thank you

  9. The name of this article should be:
    “Ruby vs CakePHP from lazy PHP developer perspective”

  10. Well said! Yes, there are several extra hoops to jump through for RoR compared to Cake. Also, it seems that Cake is in its infancy, so just give it a few more months and who knows what will be possible! I guess one thing worth mentioning is that if you’re dealing with a huge coproration that has major resources and already has a major international audience, I would go with Ruby on Rails all the way! The documentation is already there to pull of an incredible end product.