Slashdot Mirror
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."
I've worked in all three, repeatedly, and there's really no contest. Rails is so much easier to get concepts out, and has so many fewer bugs (in my experience), that it's silly to use PHP at this point, unless you have overriding reasons for choosing it aside from inherent qualities.
There are different things that you can do with a website, so first of all it really depends on what you are intending. PHP5 will be great for building creating more traditional websites that are driven by HTML forms, and is probably the best thing to use for such purposes. Ruby on Rails seems to be meant for if you are planning to build AJAX apps. It's fairly easy, with a lower learning curve, but does have scalability issues. Another option that you might consider if you are looking for AJAX stuff would be GWT, the Google Web Toolkit. Larger learning curve, but very fast web apps. Really though, comparing PHP5 and RoR seems kind of like comparing apples and oranges. Just remember, figure out what you are trying to do first, then pick the language.
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 =)
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
May I remind you all of this:
http://www.flickr.com/photos/planetargon/1279842 54/
Yes, that's the creator of RoR talking about what he feels about other people not liking his framework. RoR is all about pretty code, if you don't like RoR, use something else.
So, that sorted that out. Now, troll!
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.
/wasted/ a month learning into it). RoR has some hot ideas but it tries to be too smart and locked down for its own good.
You have the right idea about RoR (speaking as someone who excitedly spent
CakePHP is a typical PHP open source project: random code, bloated, no direction. It's also cool, in a way, but I'd never run big project on it.
One promising framework for PHP appeared to be Mojavi, but it later stalled and was forked into Agavi. Agavi tends to try to be way too flexible for its own good (unlike RoR), and in the end is just not simple to use. There's just too much stuff in there you'll never use in a real world project, which complicates code understanding and development.
I also find the "CakePHP vs PHP5" question to not make any sense, I'm sorry.
I recently finished a long comparison of PostgreSQL and MySQL in the context of mission-critical data that gives a lot more detail on the issues you bring up here.
Well, I "checked" Twitter. Are the authors of the other ones also on record saying the technology they chose fails to scale?
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
If you had really complete freedom and were willing to try out something radically different from existing frameworks, I would suggest you would take a look at Ocsigen. It is based on the OCaml language, which alone implies a different mindset from traditional frameworks based on imperative languages. Some of Ocsigen's cool features:
Sorry if this sounds like a sales pitch, but I would just like to point out that there are wonderful technologies out there, if people were just willing to take a step outside the trodden path.
Hell, even the Ruby, and Ruby on Rails site http://shiflett.org/blog/2006/feb/php-easter-eggs> need PHP in order to scale
This is my sig. There are many like it but this one is mine.
Well, you can get specific like that, yes. But please, follow the story to its completion. The issue was solved, and easily solvable from day one. (For a better solution to the same problem, see this link.)
I currently write chronically non-scaling Rails apps myself. I can write apps in Rails that scale well, but it turns out there's a huge market for sites that don't need to, and that's where I'm spending some time these days. I've also worked on a nicely-scaling social network site in Rails. There are plenty of tutorials on how to make sure your Rails app scales, but here are the things I'll have to do to my company's custom CMS to make it scale:
Oh noes! The horror! Then it's up to Apache to handle pretty much every request. Of course, my use case only has to make static content scale. As long as you're actually writing nice stateless apps on the web, in whatever language, they'll scale. If a given URL has static content across visits, they'll scale insanely well, because you don't Mb>use RoR to serve the site in those cases, you use Apache.
-knewter
You're totally off base but so is this article.
PHP is comparable to Ruby or ModRuby. Ruby on Rails is a framework.
Of course there's no scaling issues with these languages because they're just programming languages. Things like load balancing are something YOU have to take into account as you build your website and manually handle. You can architect things anyway you want, so if stuff fails it's your fault. This means DB transactions, sessions, templating, etc. are all things you have to handle. The language can't be at fault for these things.
Ruby on Rails is slower for many things because it saves you upfront development time and makes refactoring and adding features a breeze. For many people this is perfectly fine. I write intranet apps for my company in RoR all the time, and it's great. We do not handle many users, but we DO care about getting functionality fast.
Also, for some ridiculous reason people seem to think that RoR does not scale because an out of the box RoR stack may not scale perfectly (like Twitter). RoR may be slower than a tuned PHP script in some cases, but it scales horizontally just fine.
Lots of people may think Twitter and say RoR doesn't scale. But what they don't know is that twitter didn't scale because their DB didn't scale to handle that many writes. You can always throw more boxen at rails and get a larger pool of Rails processes to distribute the load to. You can throw Memcached at it to speed up queries as well, but at the time the whole Twitter complaint happened Rails only supported one database connection. This was fixed soon after. The fact is though, that once you have a service with so many reads and writes like twitter, out of the box ANYTHING is going to suck. Rails, however, gained the necessary functionality (Magic Multiconnections) and allows for all the custom tweaks, performancing tuning, and caching you'll need.
Photos.