Forgot your password?
typodupeerror
PHP Programming

PHP5 Vs. CakePHP Vs. RubyOnRails? 469

Posted by kdawson
from the please-choose-one dept.
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 discussion has been archived. No new comments can be posted.

PHP5 Vs. CakePHP Vs. RubyOnRails?

Comments Filter:
  • Sure (Score:3, Funny)

    by dedazo (737510) on Monday September 10, 2007 @02:41AM (#20535349) Journal
    1. PHP: What people build real websites with.
    2. 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

    Next?

    • by Praedon (707326)
      I completely agree. PHP5 hands down.
    • Re:Sure (Score:5, Funny)

      by NickCatal (865805) on Monday September 10, 2007 @02:43AM (#20535367)
      And the award to the quickest troll in the world goes to......
      • Re:Sure (Score:5, Funny)

        by Max Littlemore (1001285) on Monday September 10, 2007 @02:55AM (#20535435)

        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 [google.com]? Thanks buddy!

      • Re:Sure (Score:5, Interesting)

        by dedazo (737510) on Monday September 10, 2007 @03:01AM (#20535463) Journal
        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 =)

        • In other words... (Score:5, Insightful)

          by jaaron (551839) on Monday September 10, 2007 @03:21AM (#20535557) Homepage

          I've never used Ruby or RoR... my experience with PHP is limited as well...

          In other words, you were trolling. :-)

          Having done websites in PHP, Rails, Python and Java, I can say that they all suck one way or another. Ruby and Rails are both very different from PHP and my personal unconfirmed suspicion is that a lot of the Rails problems people have are from programmers who jump over into Rails without first learning what they're getting themselves into. Deploying Rails can be very difficult and you can face a lot of issues that you would never face for PHP.

          Personally, I prefer Python or Ruby over PHP any day.

          • Re:In other words... (Score:5, Informative)

            by dedazo (737510) on Monday September 10, 2007 @03:36AM (#20535653) Journal

            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: (Score:3, Interesting)

              by SQL Error (16383)

              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.

              PHP doesn't scale at all. It's a shared-nothing system, so whatever scaling issues you run into are, by definition, nothing to do with PHP itself; th

              • Re:In other words... (Score:5, Interesting)

                by Foofoobar (318279) on Monday September 10, 2007 @08:55AM (#20537205)
                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 [shiflett.org]> need PHP in order to scale

              • Re: (Score:3, Informative)

                by nuzak (959558)
                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
        • Re:Sure (Score:5, Interesting)

          by suv4x4 (956391) on Monday September 10, 2007 @03:46AM (#20535699)
          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.

          You have the right idea about RoR (speaking as someone who excitedly spent /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.

          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.
          • Re:Sure (Score:4, Insightful)

            by Baddas (243852) on Monday September 10, 2007 @04:01AM (#20535779) Homepage

            You have the right idea about RoR (speaking as someone who excitedly spent /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.


            The beauty of Ruby is, even if you don't like it the way they do it, you can always monkey patch it. Open up the object and override the method(s) you don't like.

            Try doing that to the PHP core libs. Better know C, and love it a lot.
          • Re: (Score:3, Insightful)

            by Tassach (137772)

            You have the right idea about RoR (speaking as someone who excitedly spent /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.

            I had the same experience. Right now I'm trying out Catalyst [catalystframework.org] + Mason [masonhq.com] running under mod_perl.

            Catalyst takes most of the good ideas from RoR and combines them with Perl's TIMTOWTDI philosophy, rather than Rails' "our way or the highway" attitude.

            Mason is a PHP-like templating language for Perl.

        • by patio11 (857072) on Monday September 10, 2007 @04:01AM (#20535785)
          ... when the complaint is similar to "PHP is a really cruddy language to write a graphics driver in". This is true -- using PHP to write a graphics driver is like attempting to change a car tire with a banana, but thats hardly a knock on PHP, its just a mostly banal comment on choosing the right tool for the job. What Rails excels in is choosing the right job for the tool -- given that you have Rails, you now know with pretty good certainty that you can bang out a CRUD site in your target vertical of choice on a very nice timescale while still being feature-rich. That is a really, really nice feature for a platform to have for small software houses.

          Granted, I wouldn't write Digg in it, but *I'll never write Digg in anything*. Neither will 99% of the world's programmers, and for the 1% that are making social networking sitse with desired user numbers the size of nation states, they have the LAMP stack and God bless them for it.

          As for me, I've got one quite profitable desktop application written in Java (folks laughed at me for that -- what can I say, it got the job done) and am having a bloody ball working on a small business vertical app which, at $15 / account / month and low predicted need for users to interact with the app, would replace my day job income at about three dynamic page hits per hour. I have this funny feeling that Rails will scale that far.
        • Re:Sure (Score:5, Insightful)

          by dk.r*nger (460754) on Monday September 10, 2007 @04:46AM (#20536003)

          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.


          You could, you know, link to those "way too many blogs" and thus let the rest of us decide for ourselves if this is incriminating evidence against Ruby.

          "I read it on a blog" does not in any way imply truth.
          "I read it on many blogs" doesn't really make it much better.

          And until then, you shall remain a troll. After you post the links, you'll have your status upgraded to "person with an opinion, willing to discuss".
          • Re:Sure (Score:5, Informative)

            by dedazo (737510) on Monday September 10, 2007 @05:48AM (#20536299) Journal
            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.

            • Twitter Follow-Up (Score:4, Insightful)

              by jaaron (551839) on Monday September 10, 2007 @09:01AM (#20537265) Homepage

              And there's a good follow-up [romeda.org] by one of his coworkers:

              We've been extremely happy with Rails, and make use of the multitude of helpers that it offers us - like any application on any stack, though, providing fast response times to a (rapidly) growing number of users is a challenge. The solutions are often tightly coupled to the application and its characteristics, and while scaling the most trafficked Rails site in the world, we've run into situations where existing solutions weren't enough.

              Rails is best at database baby-sitting, which is not what Twitter is about and it's understandable they would have issues. Ruby is slow and we need a good virtual machine. Nevertheless, Twitter does run on Ruby which shows that it can be made to scale. Not that Twitter is a good measure of anything other than, well, Twitter. And I'm sure someone could have done it with PHP, Python, Erlang or C.

              Which is always why blanket statements about languages and platforms is always a bad idea. Just look at the comments on this article. It's just a chance for everyone to trumpet their favorite web framework or language. Sure we have our favorite tools, but most of them suck at one thing or another.

            • Re:Sure (Score:5, Interesting)

              by knewter (62953) <josh.rubyist@gmail. c o m> on Monday September 10, 2007 @09:17AM (#20537393) Homepage

              Well, you can get specific like that, yes. But please, follow the story to its completion [sharedcopy.com]. The issue was solved, and easily solvable from day one. (For a better solution to the same problem, see this link [drnicwilliams.com].)

              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:

              1. Make admins visit the site via admin.site.com
              2. Turn off page caching for admin. requests
              3. Turn on page caching for everyone else, and expire the caches every five minutes

              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.

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

          YMMV, as a RAD tool running a vertical app with a mostly normalized postgresql db which was created for the task, it delivered a lot to me.

          Of course the article submitter chooses mysql and website building as a task and the stupid comparison of a language vs. frameworks (no matter how powerful the library of the language, working with a framework is a different matter altogether, with pr
        • Re:Sure (Score:4, Interesting)

          by metalhed77 (250273) <andrewvcNO@SPAMgmail.com> on Monday September 10, 2007 @10:36AM (#20538457) Homepage
          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.
      • Re:Sure (Score:4, Funny)

        by speaker of the truth (1112181) on Monday September 10, 2007 @03:14AM (#20535523)

        And the award to the quickest troll in the world goes to......
        --
        -nick [nickcatalano.com]
        Wow, I've never seen such an honest troll before. My hat off to you sir.
    • Re:Sure (Score:5, Funny)

      by king-manic (409855) on Monday September 10, 2007 @02:47AM (#20535383)


            1. PHP: What people build real websites with.
            2. 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

      Next?


      Pfft.. Real men code websites in Java and ASP. Scalability and performance are for pussies. My server to chugs at 10 hits/minute and it likes it.
    • Re: (Score:2, Interesting)

      by crayz (1056)
      Can you describe some of your experiences scaling Rails? I'm currently serving up to 250,000 requests per-day with a handful of Rails apps, so I'm wondering where you hit the breaking point and had to switch to the crapfest that is PHP

      There's no doubt that Ruby and Rails especially are much slower in execution time than comparable code written in PHP. That said, the PHP code would be 2-10x as verbose, take far longer to write, and be far less maintainable. With Rails you just throw more hardware at it and i
      • Re: (Score:3, Interesting)

        by dedazo (737510)

        Can you describe some of your experiences scaling Rails?

        I work mostly with ASP.NET, really. Like I said in a later post, I have the impression of RoR being problematic for a lot of people, scale-wise.

        There's no doubt that Ruby and Rails especially are much slower in execution time than comparable code written in PHP. That said, the PHP code would be 2-10x as verbose, take far longer to write, and be far less maintainable.

        That is a tradeoff, of course, and it's really up to each person to decide the mer

    • Re: (Score:3, Interesting)

      by Cafe Alpha (891670)
      That may change. I'm working on a native code Ruby compiler right now.

      It's based (among other things) on the principle that you can optimize to your hearts content as long as you have the ability to de-optimize running code (and data) when something changes and your optimizations are no longer valid.
    • Re:Sure (Score:5, Informative)

      by CastrTroy (595695) on Monday September 10, 2007 @08:50AM (#20537165) Homepage
      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.
  • by poopdeville (841677) on Monday September 10, 2007 @02:43AM (#20535359)
    Great, a link to a wikipedia article. Wonderful.
  • by Anonymous Coward
    This seems to be yet another kdawson story which exists to solely promote the "my X is better than yours" bashing, trolling and flames that always seem to follow these stories. Come on, can we get a new editor already?
  • Brrrr... (Score:2, Insightful)

    by jfclavette (961511)
    I can't comment on Ruby on Rails, but PHP (yes, even PHP5) is such an horrible language. Yes, it's widely available and is pretty much the only option out there for free/cheap hosts, but I just don't understand why someone would choose to use it in any serious project.

    JSP and ASP.Net (Yes, I know, this is Slashdot) are, IMHO, much more much more powerful and pleasant to work with. If I had to pick amongst the proposed solutions, I'd pick RoR if only for the fact that Ruby is a nice language. I don't know
    • Re:Brrrr... (Score:5, Insightful)

      by Baddas (243852) on Monday September 10, 2007 @03:00AM (#20535453) Homepage
      JSP and ASP are terrible compared to rails. You really ought to pick up Agile Web Development with Ruby On Rails [amazon.com] and go through the sample project at least.

      It'll change the way you think about development for the web.

      Or, if you're really set on Java, try Rails for Java Developers [amazon.com] and you'll see how much more concise the exact same code is in Rails.
      • Re: (Score:3, Insightful)

        JSP and ASP are terrible compared to rails.
        In speed of development, yes. But what about perfomance, scalability, and reliability? How about amount and quality of available documentation?
    • by pembo13 (770295)
      Well at least you qualified it by saying in your opinion. Just to share mine, having used PHP and ASP.net, I rather work with PHP for free than be paid to use ASP.NET. I do use both however.
    • Re:Brrrr... (Score:5, Insightful)

      by @madeus (24818) <slashdot_24818@mac.com> on Monday September 10, 2007 @03:50AM (#20535721)
      Compare a straightforward Java class, with try/catch (a silly example, but obviously just to provide some syntax):

      public class DoStuff {
          protected double someNumber;

          public setSomeNumber( double number ) {
              try {
                  someNumber = number;
              } catch (Exception e) {
                  // See e.getMessage() for error
              }
          }
      }

      ... with some PHP for the same code, which would look like this:

      public class DoStuff {
          private someNumber;

          public setSomeNumber($number) {
              try {
                  $this->someNumber = $number;
              } catch (Exception $e) {
                  // See $e->getMessage() for error
              }
          }
      }

      I don't see how that's wacky syntax in the slightest. Just people people use PHP like it's Perl+Mason doesn't mean you can't use PHP for serious, scaleable, enterprise software. I know from experience that people are just as likely to write nasty Perl, Ruby or ASP as they are nasty PHP.

      Personally I think Java makes it more difficult to be wacky (even though of course it can't force people to write code that's ultimately good) and that has definite benefits in an enterprise environment, but that lack of flexibility (which scripting languages like Perl and PHP have) is also why I don't tend to want to use Java.

      • Re: (Score:2, Insightful)

        by Anonymous Coward
        The problem with java is not the coding, it is the ridiculous amount of hassle you get in deploying multiple apps on a single server. Having to change XML config files buried in archives, ClassLoader problems because two apps need to use the same (or different versions of the same) library. Stupid hassles when versions upgrade which serve no real purpose (moving classes from java.what.ever to javax.what.ever).

        Java is great if you work on a single application with its own hosting environment, if you need mul
        • Re: (Score:3, Informative)

          by jrumney (197329)

          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 J

  • Rails (Score:5, Interesting)

    by Baddas (243852) on Monday September 10, 2007 @02:48AM (#20535393) Homepage
    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.
  • by 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.
    • by corychristison (951993) on Monday September 10, 2007 @03:08AM (#20535489)
      I agree.

      Lately people (aka: script kiddies) seem to be losing the distinction between what is a language, and what is a framework. I cannot remember the last time I downloaded a PHP script and it required PEAR. I absolutely despise PEAR, and all other frameworks that really don't seem to have a place.

      Over the past 5 years or so (I develop websites for a living) I've developed a framework-style setup that I use for all new projects. Most sites don't share the same code as I develop project-specific. But the structure is the same, and in most cases I could grab a pile of files from one site and plop them in the next and it would work.

      Use the tool as it is meant to be used. PHP is a language. A framework is a framework. Please don't compare them on the same level.

      • Re: (Score:3, Insightful)

        by RegularFry (137639)

        Use the tool as it is meant to be used. PHP is a language. A framework is a framework. Please don't compare them on the same level.

        Except that in this case, the comparison is valid. PHP without a framework is, if you will, the null framework. Its advantages are that there is no learning curve, deployment is trivial, and there's no runtime framework overhead to heat up your CPUs. On the other hand, it doesn't help you at all in writing the app, and once your site gets beyond a certain size you'll probably

  • by javakah (932230) on Monday September 10, 2007 @02:53AM (#20535425)
    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.
    • by AaronBrethorst (860210) on Monday September 10, 2007 @03:12AM (#20535509) Homepage

      I disagree. Rails is fantastic for quickly rolling database-driven forms apps. It includes some nice helpers for quickly integrating asynchronous behavior (Ajax), but it's certainly not mandatory. PHP5 doesn't include an OR mapper, and nor should it; an OR mapper should be part of a separate framework or library (just as it is with Ruby and Ruby on Rails). I think that Rails actually has a fairly steep learning curve. It has *very* specific ways of handling most things, and trying to fight against these things will only come back to hurt you in the end. Additionally, since it requires you to function in an MVC mode, there might be an additional bit of learning present as you figure out how to properly separate your app into presentation, model and controller layers.

      At the end of the day, it all comes down to need and experience. If you know how to use PHP, why not use it? If you have to integrate a new feature into an existing Rails app, then you'd better learn Rails in a hurry. Personally, I'll build Windows server-targeted web apps in ASP.NET because I know the tooling and the backend. If I'm hosting on Linux or UNIX, I'll write it in Rails because the language and frameworks are so much nicer to use than PHP.

      • by misleb (129952)

        I think that Rails actually has a fairly steep learning curve. It has *very* specific ways of handling most things, and trying to fight against these things will only come back to hurt you in the end.

        Rails only has a steep learning curve because most people learning Rails are also learning Ruby for the first time. Learning a language and a framework simultaneously is hard. Ruby, by itself, is actually very easy to learn... principle of least surprise and all that. And if you're already know Ruby, are comf

    • Re: (Score:3, Insightful)

      by misleb (129952)
      Rails for Ajax stuff? There are WAY better reasons for going with Rails than to get Ajax. A proper MVC framework, for starters. Rails is really meant for building *applications,* not necessarily "sites." If you can frame your site as an application, great, but don't expect Rails to power (well) just any old site.

      And, yeah, comparing Rails to PHP5 is kinda dumb because Rails is a framework and PHP5 is a language. The problem with using "PHP5" in any non-trivial application is that you invariably end up build
  • by david_bonn (259998) * <davidbonn&mac,com> on Monday September 10, 2007 @02:59AM (#20535447) Homepage Journal
    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: (Score:3, Insightful)

      by Bluesman (104513)
      "but in reality, how often over the lifetime of your website will you migrate to a different database?"

      If you told me I could pick either the database to use or the scripting language to code in, I'd pick Postgresql and let you pick the language. Most of the things people try to do in scripting languages can be handled in the database much more elegantly and scalably. Of course, most people don't realize this because they've only used MySQL and don't realize how much it's missing.

      If you told me I could pi
  • Focus.. (Score:3, Interesting)

    by August Lilleaas (1111117) on Monday September 10, 2007 @03:03AM (#20535473) Homepage

    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!

  • Django (Score:2, Informative)

    Django [djangoproject.com] anyone ?
    • by Gordonjcp (186804)
      Seconded.
  • Easy (Score:5, Informative)

    by OriginalArlen (726444) on Monday September 10, 2007 @03:06AM (#20535485)

    PHP5 Vs. CakePHP Vs. RubyOnRails?
    Easy - mod_perl [apache.org].
  • Django (Score:5, Informative)

    by Max Romantschuk (132276) <max@romantschuk.fi> on Monday September 10, 2007 @03:11AM (#20535499) Homepage
    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]

    • Snakes and Rubies (Score:3, Informative)

      by hitchhacker (122525)

      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
    • Dive into Python (Score:4, Informative)

      by hitchhacker (122525) on Monday September 10, 2007 @03:55AM (#20535749) Homepage

      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: (Score:3, Informative)

      by daeg (828071)
      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.
  • by jaaron (551839) on Monday September 10, 2007 @03:12AM (#20535511) Homepage
    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.
  • Tapestry (Score:4, Insightful)

    by Anonymous Coward on Monday September 10, 2007 @03:15AM (#20535525)
    Or another Java framework, due to the maturity, scalability, availability of libraries, and number of people who know it.

    Rails just does not have a stable server. Webrick + fastCGI, or Mongrel, they both crash regularly for us. Also I've had to maintain several Rails apps written by others, and it sucks. All those neat tricks that makes it "productive" for the first programmer makes it difficult to understand and maintain for everyone else.
  • Python and Django (Score:5, Informative)

    by egrinake (308662) <erikg@[ ]epoet.no ['cod' in gap]> on Monday September 10, 2007 @03:15AM (#20535529)

    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.

    • Re: (Score:3, Funny)

      Python is a much cleaner language than both PHP and Ruby

      ...said egrinake, the God that Decides Which Language that Rocks More.

      • by egrinake (308662)

        Python is a much cleaner language than both PHP and Ruby

        ...said egrinake, the God that Decides Which Language that Rocks More.

        I know I'm not supposed to feed the trolls, but at least syntax-wise (and the syntax is basically the language) I'd say it is. I think you'd have a hard arguing that Python has noisier syntax than PHP at least (don't have alot of Ruby experience, but Python code seems easier to read).

    • Re: (Score:3, Interesting)

      by Richthofen80 (412488)
      almost all of the API is procedural,

      You're right, but is this necessarily a bad thing?

      The web itself is procedural. Unless you're a sadist, web applications are broken out into different URIs that handle different part of the applications. Administration functions might be in myapp/admin ... and I break up each edit/add/delete into its own .php file. This way, it is inherently clear what the purpose of each file/URI is, and the functionality doesn't bleed over into 50+ deep include'd files so you have to se
      • Re: (Score:3, Interesting)

        by nuzak (959558)
        The web itself is procedural. Unless you're a sadist, web applications are broken out into different URIs that handle different part of the applications.

        Sounds functional to me. Throw the inherent statelessness of the protocol on top for a bonus.

  • PHP5 (Score:3, Funny)

    by mrjb (547783) on Monday September 10, 2007 @03:18AM (#20535535)
    ... because I know it and I know it does the job. Also saves me the work of figuring out what CakePHP and RoR is.
  • by jalmond (1154263) on Monday September 10, 2007 @03:28AM (#20535599) Homepage

    What we have here is another usual question that all really depends on your project type. That being said, I'll try to break from the typical, slashdot format and attempt to address your question:

    1. Maturity of Solution: 1st PHP5, then Ruby, then Cake. Shouldn't be a lot of controversy here. PHP has been around since the dinosaur age, ruby came around with all that slick don't repeate yourself talk and then cake came about and tried to add ruby like framework to PHP.
    2. Features is really going to depend on what your looking for. Rails allows you to write a lot of fairly complex stuff quickly, cake arguably has better built in security, PHP5 will scale better then any of them.
    3. Everybody and their mama knows php5, any new kid thats worth a darn is probably learning rails, and then there's cake, which has nowhere near the dev support of the other two.
    4. Rails wins here if your starting from scratch, but since so many devs already have php experience, complexity becomes sort of relative.
    5. For better or worse, if you were to poll most devs that are building commercial production apps (at least out of the three options mentioned) php5 is going to win hands down. For my company it was a simple decision that hinges on two of the points: scaling and experience. We wanted something to scale to slashdot numbers, while being able to hire a bunch of kids from college to help the dev team build it all. Typical of online startups, we wanted the most bang for the bucks, and php5 was the choice.

    P.S. A similar question of Rails vs PHP vs Java question was somewhat subjectively discussed late last year http://www.cmswire.com/cms/industry-news/php-vs-ja va-vs-ruby-000887.php [cmswire.com]

  • CakePHP vs PHP5? Do they think that PHP5 is a framework? Has the name not tipped them off that CakePHP is written in PHP? How can you have PHP vs. "thing written in PHP"?
  • by MBoffin (259181) on Monday September 10, 2007 @04:01AM (#20535791) Homepage
    Sorry, can't say much more than that. If you've never used Ruby on Rails, I'm sure CakePHP would be a joy to work in. However, if you've used Ruby on Rails, then CakePHP will hurt. The Ruby language is beautifully suited to this kind of framework, and PHP is not.

    This is not to knock CakePHP. In its own right, CakePHP is an excellent framework and a lot of quality work has gone into making it what it is. It's a powerful framework.

    The move to this kind of framework can be quite a mind job, whether you're moving to Rails or CakePHP. It requires breaking down very solid foundations of ideas that you've built up over the years on how to build a web application. If PHP is your thing, then weathering that mind job will be all the more easier if you're doing it in a language already familiar to you. But if you're willing to try something new, then it's worth making the jump to Ruby on Rails.
  • PHP5 is assembler compared to the other two. and not even like assembler compared to c - php5 is actually a everyday usable 'assembler'.

    go pro. go php5.
  • Django. (Score:3, Informative)

    by imbaczek (690596) <imbaczek@pocz t a . fm> on Monday September 10, 2007 @04:19AM (#20535889) Journal
    They all suck anyway, django IME sucks the least.
  • by fozzmeister (160968) on Monday September 10, 2007 @04:26AM (#20535925) Homepage
    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.
  • by jorgegv (87225) on Monday September 10, 2007 @05:01AM (#20536045)
    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.

  • by Qbertino (265505) on Monday September 10, 2007 @05:46AM (#20536285)
    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.
  • by dankelley (573611) on Monday September 10, 2007 @06:58AM (#20536583)

    A key issue, in contrasting PHP with RoR, is deployment.

    Deploying PHP is easy in most environments, perhaps as much because of its age as because of its inherent character. I work in an academic environment, in which all professors and students have the ability to make PHP sites. Each of my personal computers also lets me make PHP sites with no difficulty. Deployment amounts to no more than a file copy, perhaps with a change of file permissions. (I won't mention the database work, because of course it is the same for all schemes, PHP, RoR, etc.)

    But, unless you're using a host that has been set up to server RoR, deployment may involve changing Apache configuration files, compiling new Apache modules, etc. Such changes require root access (not available to folks sharing machines), and have the potential to break the other sites on the machine.

    I think there is a reason why the RoR tutorials, books, and promoters so seldom mention deployment: it is difficult for many people in non-commercial environments that are not set up for RoR.

    Oh, and one more thing. All of this fiddling with apache is boring to those who have set out to create websites. Learning Ruby to do RoR is quite fun, actually, and it has the advantage that it lets you use Ruby for other tasks as well. But learning apache doesn't help you with anything but apache; it's a bit of a single-lane road.

    RoR has a sort of elegance about it, and you gain a great deal of functionality from the system (e.g. for logins, etc.), and so it is a terrific tool for rapid development, particularly of an evolving idea for a site. It sounds crazy, but the optimal path may be to write the site in RoR and then rewrite it in PHP, so that deployment will be easy and so that the site will scale well[*].

    * -- I've not mentioned scaling and speed because these issues are covered in other posts here. Basically, RoR is not impressive on either.

  • Ocsigen (Score:3, Interesting)

    by Cultural Sublimation (884893) on Monday September 10, 2007 @08:05AM (#20536869)

    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 [ocsigen.org]. It is based on the OCaml [inria.fr] language, which alone implies a different mindset from traditional frameworks based on imperative languages. Some of Ocsigen's cool features:

    • Extends the OCaml type-safety into the generation of XHTML. This means that producing valid XHTML is not only "nice", but actually enforced by the framework: your programme won't even compile otherwise!
    • The entire site is seen as a programme where each public URL is a function. The OCaml type-safety is extended to forms and internal links, meaning there can't be any inconsistencies whatsoever.
    • With database bindings such as PG'OCaml [merjis.com], you can extend the type-safety also to database access. Think about it: the compiler checks at compile-time if your programme is consistent with the database itself!
    • Functional programming is very high-level, which means rapid development and happy programmers.
    • It is fast. And by fast I mean really, really, fast. How would you like your web framework to generate native code whose speed is close to that obtained with C?

    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.

  • I learned PHP once (Score:4, Insightful)

    by seebs (15766) on Monday September 10, 2007 @09:44AM (#20537659) Homepage
    Everyone talked a lot about PHP.

    I started learning it. By about a chapter into the PHP book, I was thinking "holy crap, this language is uglier than perl". It has everything you would expect from a language thrown together by people who were either ignorant of software engineering or aware of it, but aggressively hostile to it. Everything global by default? WTF?

    I have never seen a language with so many carefully crafted security holes that the developer needs to learn to avoid. Default behavior for inclusion is to allow URLs, so you can, you know, run code from any site in the world. There's a feature everyone always wanted, which is never going to be subverted!

    I made it through about two and a half PHP books. In that time I learned that the MySQL and PostgreSQL interfaces were substantively different, and of course, used differently-named functions with slightly different calling conventions. Why? Because there's no abstraction or generalization going on; just whatever features sound cool getting thrown in with some name that wasn't previously in use. I learned that this is just BASIC all over again.

    I spent several days thinking hard about bleach, and went back to programming languages that were designed with some kind of consideration given to the development of larger projects.

    Ruby's undoubtedly "slow". That's what everyone said about perl and awk, too. Come to think of it, I've had people tell me that C was too slow. But Ruby has the amazing, shining, virtue that it is not a stupidly-designed or ugly language. I spent a while working with Ruby, and some helpful people pointed out that, in fact, the language does have a gotcha to watch out for. One. Not so many that you have to buy whole books full of things that you'd obviously try that don't work, open your site up to XSS, or behave erratically. No, just the one.

    Can PHP work? Sure. But the tacked-on afterthoughts provided to allow you to, in theory, if you remember to and want to put in the work, use basic software engineering principles, are not enough. The language provides a huge array of runtime functionality, with a function for everything. It doesn't provide the basic tools you want for engineering large projects, meaning that the workload of maintaining big stuff in PHP is exponential, not just quadratic.

    It can be made to work, but it really is that badly considered, and I wish people would stop doing things in it. Life is easy enough for the botnet people already, we don't need a language in which you have to be warned not to set the flag that lets remote sites set every global variable in your program.
  • Perl Catalyst (Score:3, Informative)

    by mattr (78516) <mattr@teleb[ ].com ['ody' in gap]> on Monday September 10, 2007 @03:16PM (#20543153) Homepage Journal
    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.

Computers are unreliable, but humans are even more unreliable. Any system which depends on human reliability is unreliable. -- Gilb

Working...