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

Re:Sure

[NickCatal]

And the award to the quickest troll in the world goes to......

Re:Sure

[Max Littlemore]

And the award to the quickest troll in the world goes to......

kdawson, for posting this absolute shit as an IT story with nothing more than a link to a wikipedia article in the summary!

Congratulations!

Hey, kdawson, while you're reading this, can I just grease you up about a story I want to post about how Steam will replace electricity to power the electric kettles of the future? Thanks buddy!

the answer: it depends

[david_bonn]

Honestly, great websites and web applications have been written using all three of those products. What the best choice for your website will be depends a lot on what your website is. Each of those frameworks makes certain assumptions about how the world works, and you will be happiest with a framework that is closest to your pwn assumptions -- otherwise you'll spend as much time fighting the framework as writing your website.

Any halfway skilled programmer will be able to do useful work with any of those frameworks fairly early on, but all of them are also very rich environments, so there's always more to learn.

I've written web apps in an ungodly tangle of PHP4 and PHP 5 and Perl and using Ruby on Rails. Currently Ruby on Rails is in favor, but is far from perfect.

Probably most of my frustration with Rails and PHP 5 has to do with Active Record. My big gripes are: (1) Schemas, entity-relationship diagrams, and queries tell me how an application works -- with Active Record this information is strewn across a whole bunch of files (especially in Rails); (2) Database-independence is a nice idea, but in reality, how often over the lifetime of your website will you migrate to a different database? Usually your database is chosen for you. Usually a switching databases involves coordinating with a lot of people who you'd usually rather not have to deal with -- those issues will take far more time and energy than differences between MySQL and Oracle; (3) a pretty common design pattern for web pages is to have a form that let's you fill in a few parameters (date, maybe geographical information) into a huge multi-table select statement -- you can do that in Active Record, but basically all you gain is a marginally fancier wrapper than you would have with DBI.

Re:Sure

[dedazo]

I should probably clarify my original post.

I've never used Ruby or RoR, but my impression of it seems to be one of great expectations and not a lot of delivery. I've read way too many blogs by people who built web sites with RoR only to have them crash and burn under load. Also, the language itself seems to place a lot of importance on clever syntactic sugar, which being an old fart I automatically dislike.

Now, "scale" does not mean the same thing to everyone. There's Digg and Wikipedia, and then there's the vertical business app that gets 200 hits per day. RoR might be a good choice for the latter, not so good for the former.

Also, although my experience with PHP is limited as well, it seems to me that it's a mature enough platform with a good runtime (that tends to be confusing at times) and a *massive* user base. The amount of readily available PHP code out there is amazing. It will take Ruby quite a few years to get to that point, I think. So maybe Ruby is not a good beginner's environment, application-wise. But that's just my perception of it. PHP is more to the point. On the other hand, RoR might be more mature and stable than CakePHP, just because it's been around longer.

The best tool for the job and all that, you know?

Oh... and BTW, first post =)

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/

Wrong Criteria, Wrong Problem, Wrong Solution

[jaaron]

What about the requirements of the, you know, actual website application?

You've provided no information on the actual website that you intend to develop. That's the important part -- the features and functionality to the customers and end users.

Instead of considering the features of the language and framework first, how about the features of the application? How many users? Who will be supporting it? What kind of server resources are available? Do you need internationalization? What's the roadmap for the site over the next 3 to 5 years? Maybee then you can map the features of the website to the features of the framework or language, such as the maturity of the libraries directly related to your webapp.

But picking the implementation language independent of the functionality of the website is a classic sign of solving the wrong problem. I don't care what you program it in, if you're asking these questions first, you are programming it in the wrong language.

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

[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:In other words...

[Foofoobar]

I ran PHPulse, the world's fastest MVC framework for PHP with a 10 terabyte database backend gets millions of hits daily and having to send data to our team in Manila and Tijuana. PHPulse gave us near split second page loads. As for not scaling, tell that to all the companies like Disney, IBM, AT&T, MTV and others who use it on their frontend. It's the most widely deployed web language out there and there is example after example after example of it scaling.

Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs> need PHP in order to scale