PHP5 Vs. CakePHP Vs. RubyOnRails?

OldJavaHack writes "If you could start a website (with MySQL for persistence) from scratch and you had a choice of PHP5, CakePHP, or RubyOnRails — which would you choose and why? Things to consider in your decision: 1. Maturity of solution; 2. Features; 3. Size of community of skilled users (to build a team); 4. Complexity/ease of use (for neophytes to master); 5. Greatest strength of your choice, and the greatest weaknesses of the other two. Here is a comparison of capabilities."

Comments

Easy

[OriginalArlen]

PHP5 Vs. CakePHP Vs. RubyOnRails? Easy - mod_perl.

Django

[Max Romantschuk]

Given complete freedom, my choice is Django: http://www.djangoproject.com/

Check out the tutorial, and you'll know why: http://www.djangoproject.com/documentation/tutoria l01/

Python and Django

[egrinake]

How about using Python and Django? Python is a much cleaner language than both PHP and Ruby, and Django makes it a joy to build web-sites.

I've been lead developer of a large enterprise system written in PHP for the last few years, and grown increasingly frustrated with just how ugly PHP is. Object-orientation has been tacked on as an after-thought (almost all of the API is procedural, without using exceptions for error-handling), the API is messy and inconsistent, it's somewhat inefficient (has to parse all the code for each request, unless you use an opcode cache), and the syntax is just plain ugly when compared to Python.

Never tried Ruby on Rails, but you should at least give Django a spin before deciding.

Re:In other words...

[dedazo]

In other words, you were trolling.

Nope. I know enough about high-scaling distributed applications to be dangerous, since that's what I do for a living. I know PHP runs sites like Wikipedia and Digg, among others. I know I've never seen a blogger go on record to complain about PHP not scaling as he expected, while for RoR that sort of thing seemed quite common in the last year and a half or so.

Yes, your execution can suck and so it won't really matter what language or stack you use. But the impression I have of RoR is that it falls apart a lot faster than PHP under comparable loads. Maybe the crappy internal design PHP suffers from might be an advantage in this case, because Ruby is designed better but it seems to suffer from classic bottom-heavy OO problems you see in other languages.

Ultimately the person who submitted this might be building an accounts receivable app at a little company that gets three hundred hits per day, so it won't really matter if he writes it with Ruby, PHP or Malbolge.

language, framework, framework

[fozzmeister]

PHP5 is a language, the other two are frameworks. So it can't really be compared. The Zend Framework is a very non-limiting non-rigid framework (it's much more like a bunch of really good libraries atm) which might make the comparison viable.

Perl advocates should try CATALYST

[jorgegv]

I find it strange that nobody yet has given a reference to Catalyst, the best MVC framework for Perl. From people that have tried both (not me), it is said to be the equivalent of RoR for Perl. I can't back that because I'm a perl monk and I don't have time for yet another language (what for, when you have already tried the best language ? ;-)

Application skeleton and database CRUD in 30 seconds (measured!!!). Try it.

Symfony (PHP 5 Framework), Notes on other Webkits

[Qbertino]

As many have pointed out allready, PHP (incl. PHP 5) is a subset of CakePHP, as it is - Tadaa! - a PHP Framework. So if you run Cake on PHP 5 (it runs on both PHP 4 and PHP 5) then you've got both.
There are a lot of Frameworks recommended here, such as Django, Turbogears and others. They are all very neat. I'd like to add Zope (or it's superset Plone) to that list as it is the oldest and most mature of all these neat OSS Webkits.

Rails is the first project that emphatically applied marketing tactics to make itself popular, thus the extreme hype surrounding it and the potential critical mass it has gained. It's simular to the hype Zend is putting behind it's Zend Framework right now. Which is also way overhyped with bold claims despite being less than a year old. However Rails is *not* the Framework that invented or first implemented MVC, Scaffolding or all the other concepts associated with it.

A Webdevelopers 2 cents.

Feature, concept and technology wise Zope (built with Python) is still unmatched by any other Framework or Appserver available, be it in Python, Ruby, Java or whatever.

CakePHP is a good Framework - I'm using on PHP 5 it just now to build a larger custom CRM System - and the community is fun (no Forum - we all hang out on IRC) but I recommend Symfony, as it is built entirely on PHP 5 no extra work added for PHP 4 compliance, covers aspects of it job by integrating existing Projects such as Creole and Propel for the DB stuff and it has very good documentation. Including a very well written Book (free PDF version available). Symfony is mature and has been successfully used in very large scale Projects (Yahoo Bookmarks is built on it).

Bottom Line: I'd be carefull not to blindly follow the rabid hypers of Rails or their fresh PHP equivalent, the Zend Framework bandwagon crew. Check out the Frameworks people have mentioned here and if you want to stick to PHP 5 Cake or Symfony are both fine choices.

Re:Sure

[dedazo]

Sure. Here's a quote from an interview with the guy that created Twitter:

How has Ruby on Rails been holding up to the increased load?

By various metrics Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there's no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it's not just cost, it's time, and time is that much more precious when people can['t] reach your site. None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.It's also worth mentioning that there shouldn't be doubt in anybody's mind at this point that Ruby itself is slow. It's great that people are hard at work on faster implementations of the language, but right now, it's tough. If you're looking to deploy a big web application and you're language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it's worth being frank that this isn't one of those relativistic language issues. Ruby is slow.

Is that specific enough for you?

And until then, you shall remain a troll.

Would you like some salt to go with your crow? Let me know.

Re:Sure

[CastrTroy]

A bit of advice. Use PDO. Don't use MySQL or MySQLi functions. This will not only make your life a little easier if you ever need to switch database engines, but I also find that it makes doing prepared queries much easier (although it's possible with MySQLi). Being mostly a .Net developer, I find it hillarious and sad that most PHP tutorials recommend using the mysql_ functions, along with mysql_real_escape_str() function for doing database queries. One interface for all databases makes a lot more sense, and using prepared queries protects against SQL injection in a way that trying to remember to use mysql_real_escape in every query can't come close to.