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

10 of 469 comments (clear)

  1. the answer: it depends by david_bonn · · Score: 5, Insightful
    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.

  2. Re:Brrrr... by Baddas · · Score: 4, Insightful

    JSP and ASP are terrible compared to rails. You really ought to pick up Agile Web Development with Ruby On Rails 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 and you'll see how much more concise the exact same code is in Rails.

  3. Re:Errr, this is a new story by corychristison · · Score: 4, Insightful
    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.

  4. Wrong Criteria, Wrong Problem, Wrong Solution by jaaron · · Score: 5, Insightful

    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.

    --
    Who said Freedom was Fair?
  5. Tapestry by Anonymous Coward · · Score: 4, Insightful

    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.

  6. In other words... by jaaron · · Score: 4, Insightful

    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.

    --
    Who said Freedom was Fair?
  7. Have your cake/php/rails and eat it to by jalmond · · Score: 4, Insightful

    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

    --
    Travature.com: Hello...World
  8. Re:Brrrr... by @madeus · · Score: 4, Insightful

    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.

  9. It makes little sense to say Rails doesn't scale.. by patio11 · · Score: 4, Insightful

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

  10. Re:Sure by dk.r*nger · · Score: 4, Insightful

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