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."

Errr, this is a new story

[Anonymous Coward]

This is more an ask slashdot post. And even so, CakePHP and RoR are frameworks while PHP is a language.
That being said, CakePHP is fantastic and for anything past simple scripts, I am finding CakePHP speeds up development greatly.

Django

[son of a submariner]

Django [djangoproject.com] anyone ?

Easy

[OriginalArlen]

PHP5 Vs. CakePHP Vs. RubyOnRails?

Easy - mod_perl [apache.org].

Django

[Max Romantschuk]

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

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

Python and Django

[egrinake]

How about using Python and Django [djangoproject.com]? 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.

Snakes and Rubies

[hitchhacker]

There was a good video, although outdated (2005), that had two of the main developers of Django and RoR. The video is quite long (3hrs), so I'll link to the Google Video Search [google.com]. The second and third are each person's presentation, and the fourth, which I recommend, is a Q/A session.

-metric

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.

Re:Django - Fourthed

[hpoul]

imho django is really the easiest web framework to develop in.. It's ORM is flexible and powerful but compared to hibernate & co so much simpler that it is just shocking ..
i have developed in perl, php, java (webwork with hibernate and IoC containers and what-not) but with django you can get things done much faster and get cleaner results..

(and some self-advertising - look at my project http://sct.sphene.net/ [sphene.net] - forum & wiki applications based on django)

Dive into Python

[hitchhacker]

Whether it's Ruby on Rails, or Django, most developers will have to learn a new language. Python has a book available online: Dive into Python [diveintopython.org]. I found it very easy to switch from C/C++/PHP to python. Django does have a slight learning curve though. Oh, and be aware, the Django documentation online is for their SVN version! Most likely NOT your distro's version. They are still under heavy development.

-metric

Re:Dive into Python

[ubernostrum]

Oh, and be aware, the Django documentation online is for their SVN version!

Well, you can start the tutorial here [djangoproject.com] for the SVN version, or you can read the big warning at the top of the page which links to documentation for the various releases, and find:

• The tutorial for Django 0.96 [djangoproject.com]
• The tutorial for Django 0.95 [djangoproject.com]
• The tutorial for Django 0.91 [djangoproject.com]
• The tutorial for Django 0.90

So long as you can read large text at the top of every page, and click clearly-offered links, you can read the documentation for dev version, or for any stable release we've ever done.

Django.

[imbaczek]

They all suck anyway, django IME sucks the least.

Nriyh

[Anonymous Coward]

Well I guess it depends what you are building. Ruby on Rails is certainly a fun framework to work with. The trouble is Ruby itself is painfully slow (see http://shootout.alioth.debian.org/ [debian.org] for data on this) and doesn't get Unicode. So if you're site is going to do anything large or international it would be a poor choice. If not then RoR is a lot of fun - go for it.

PHP. People do build large apps in PHP. Having used it quite a bit it remains a mystery to me a)how and b)why. Its ugly and handles state poorly - a disaster for a web language in my view.

Alternatives. Both Java and ASP.NET make sense for large scale applications. Beyond that it depends a lot what you're doing. I would tend to plump for Java since I like being able to pick the right framework for the job I'm doing - so for instance if I'm building a high traffic web app I'd probably go for Struts, if I was building something that needed to be more desktop like I'd probably go for JSF with Seam, and if I was after lots of Ajax bells and whistles I'd probably add GWT into the mix. I also like the richness of the Java toolbox (being able to use JMS to talk to MQ for instance, applets on the client side for certain specific duties), and the Java tools (notably IDEA) are world beating.

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.

Re:Sure

[saveourskyline]

RoR: What people build websites with because they want to be kewl and later switch to PHP when they realize it simply does not scale, complete with acerbic "I wanted to believe" blog entry and everything

You might want to check out YellowPages.com, Twitter.com, and OpenCongress.org.

Uh .. if you're comparing frameworks

[aderuwe]

If you're mostly comparing frameworks anyway (CakePHP and RoR are frameworks, PHP5 is a language) just substitute symfony [symfony-project.com] for PHP5, and the answer becomes clear: use symfony... The best of PHP5 with the best practices of RoR - just make sure to use an opcode cache because symfony is not the most light-weight.

Scalable, and loads of fun to program with.

Perl advocates should try CATALYST

[jorgegv]

I find it strange that nobody yet has given a reference to Catalyst [catalystframework.org], 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 [perl.org] ? ;-)

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 [symfony-project.com], 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 [radicalbehavior.com] 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:Brrrr...

[jrumney]

Having to change XML config files buried in archives

That would be a problem with a specific application's packaging, nothing to do with the language that was used to code it.

ClassLoader problems because two apps need to use the same (or different versions of the same) library.

J2EE specifies application specific library directories, which is how you should be deploying them. If you are deploying your libraries into a shared directory and modifying the classpath, then it is you that is at fault, not Java.

Stupid hassles when versions upgrade which serve no real purpose (moving classes from java.what.ever to javax.what.ever).

What version upgrade moved something from java.what.ever to javax.what.ever? I've seen packages move from com.third-party.what.ever to javax.what.ever when they were accepted as a standard library, but never something incompatibly moving within the java/javax namespace.

Re:Django

[daeg]

And Django isn't limited to blogs, wikis, etc. I run a complete medical management (medical record, inventory, staff tracking, chart/lab tracking, third party medical equipment integration) on Django quite happily out of 20 (and growing) offices across the states.

The only negative side is the lack of Python developers. I've found a handful around here (Tampa) but they seem to be a rarity. I can find a few Ruby developers, but their extent of Ruby is only RoR tutorials, it seems.

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.

Re:Sure

[Just Some Guy]

Crud. I replied to the wrong post.

Does such a concept protect against SQL injection or not?

No. That is, it's not the right (and easy!) way to handle it, so you can assume that someone will invent a clever workaround that will defeat your code. Really, just use named parameters and be done with it. It's easier than building your queries by hand and far safer, so there's no reason whatsoever not to do it.

Re:Sure

[tenaciousj]

As pointed out a few post up, their problem with database scaling was solved quite quickly i believe:

http://www.loudthinking.com/posts/3-scaling-to-multiple-databases-with-rails [loudthinking.com]

Re:Sure

[CastrTroy]

Sorry to tell you this, but it very much doesn't. First, and not even related to whether it protects or not, is that it very much limits when someone can post to your server. If I need to post my name, and my name is Walter, then your script is just going to die. On the question about how well it works for blocking attacks, well, like mysql_real_escape_str, is what happens when you forget to use it. With prepared queries (not talking stored procedures here, so I don't scare anyone away), it's a completely different method of creating a query, and therefore it isn't very easy to "forget" something, and leave a vulnerability. Also, there's probably a large list of words you could be fogetting to check for. Stuff like "RENAME SCHEMA" may not be in your list, but could cause a DOS attack. You wouldn't lose any data, but your database would be renamed and therefore your site inaccessible to users. Your solution would protect against a common script kiddie, but wouldn't protect against someone who is determined to bring your site down. Using prepared queries is very easy to do, makes your code easier to read and maintain, and also speeds up database access. There really is no reason not to use it.

Re:In other words...

[Anonymous Coward]

> PHP doesn't scale at all. It's a shared-nothing system

It's true that PHP doesn't scale for shit (Wikipedia solves the problem through sheer brute force that costs no small amount of $$$). But shared-nothing isn't the reason for that. Shared-nothing in fact scales better than anything else, since there is no contention and no deadlock, not even temporary. Takes a lot more resources at first, but it scales out better in the long run.

Amazon runs largely on message-passing service interfaces, for starters.

Re:Easy

[Llarian]

http://www.catalystframework.org/ [catalystframework.org]

Catalyst is mature, activly supported, and being used in a lot of locations. (Sixapart's Vox being the largest example)

So, no, we haven't been pushed out of the web market by other lauguages. Thanks for asking. =)

(There's Jifty too, but I have no person experience with it)

Re:In other words...

[nuzak]

I think the only languages you can really call "shared-nothing" would be ones like Erlang or Occam -- otherwise, it's an attribute of an architecture, not a language. PHP has built-in support for sessions, which have a larger scope than the interpreter itself. That's shared-something all right, and it kills scalability real good if you don't invent your own session management stuff on top of PHP's built in nonsense.

I hate PHP with the power of a thousand suns, but scalability isn't one of the reasons. It's just a not very good language (to put my opinion mildly) but it has the library support for enough things from memcached to mqseries in order to build decent and very scalable architectures on. The execution speed of the language is usually adequate, at least for most apps that fit in its domain. It's other pieces of an out of the box LAMP architecture that usually fail: running apache in prefork mode is, for example, not one of the wiser scaling decisions to make.

Re:Sure

[nuzak]

> Does such a concept protect against SQL injection or not?

DROP TABLE Customers;

You also forgot to enumerate every stored procedure that might be callable, or guard against injecting unauthorized columns in those really dynamic queries that specify columns as parameters.

Bound parameters protect against SQL injection without having to interrogate every bit of SQL and praying that you covered every attack. With bound parameters, something that real DB APIs have supported from day 1, you don't need goofy hacks like this. Even PHP supports them for a few databases now, I think.

They're also faster and actually easier in the long run. Really, it's only PHP and the early-90's VB folks that even have to be told this sort of thing. Everything else got with the program long ago.

Perl Catalyst

[mattr]

1. Maturity of solution;
Catalyst and Perl both more mature than the frameworks/languages mentioned.
2. Features;
CPAN is bigger, Perl has more functionality which is why there is more than one way to do it (TIMTOWTDI) in Perl.
3. Size of community of skilled users (to build a team);
More skilled Perl programmers.
4. Complexity/ease of use (for neophytes to master);
Mmmm well can't say. PHP based thing with only one layout you can use might be simplest for a newbie. On the other hand, are you trying to make a serious webapp or just a cookie cutter steaming phpnuke thing? Am interested in Ruby mainly because it just might reduce typing but then again maybe not. Just seems neat. But for making a live system I'd go with Perl.
5. Greatest strength of your choice, and the greatest weaknesses of the other two.
Many available modules. Other two have a much shorter [programmer pool size] x [framework and modules powerfulness] vector.