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."
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 anyone ?
Son of a submariner ! They'll pay for this...
Everything I needed to know about life, I learnt from Blake's Seven
Given complete freedom, my choice is Django: http://www.djangoproject.com/
a l01/
Check out the tutorial, and you'll know why: http://www.djangoproject.com/documentation/tutori
.: Max Romantschuk
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.
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. The second and third are each person's presentation, and the fourth, which I recommend, is a Q/A session.
-metric
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.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
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/ - forum & wiki applications based on django)
Find me at http://herbert.poul.at
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. 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
They all suck anyway, django IME sucks the least.
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/ 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.
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.
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.
If you're mostly comparing frameworks anyway (CakePHP and RoR are frameworks, PHP5 is a language) just substitute symfony 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.
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.
Reality is a mass hallucination due to lack of alcohol in blood. - DeadLiver
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.
We suffer more in our imagination than in reality. - Seneca
Is that specific enough for you?
Would you like some salt to go with your crow? Let me know.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
That would be a problem with a specific application's packaging, nothing to do with the language that was used to code it.
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.
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.
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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.
Dewey, what part of this looks like authorities should be involved?
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
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.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
> 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.
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.
Done with slashdot, done with nerds, getting a life.
> 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.
Done with slashdot, done with nerds, getting a life.
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.