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."
Next?
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Great, a link to a wikipedia article. Wonderful.
After all, I am strangely colored.
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?
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 about Rails' features but I could at least trust the language it's built on.
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.
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.
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.
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.
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 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
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?
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.
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.
... because I know it and I know it does the job. Also saves me the work of figuring out what CakePHP and RoR is.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
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?
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:
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
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
"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 pick both, I'd go with Perl, unless I were doing something very simple that's been done a thousand times before.
PHP is decent enough for what it is. Historically there have been security problems with it, and the design is crappy. But it's quick and easy.
I've never used Rails, but it sounds like it does a lot for you. In my experience, that can be a blessing if you're doing something textbook. If not, have fun fighting with the assumptions other people made.
If moderation could change anything, it would be illegal.
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.
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
... 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.
Help poke pirates in the eyepatch, arr.
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.
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.
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
The paradigm of having web pages that you serve, and that are actually files on the server only works for a short time. Mixing any of these inline scripting languages into the HTML document stinks IMO.
As soon as your website is a bit dynamic you are better off generating everything on the fly.
You can describe content with databases and xml and CSS and then have your server generate actual pages from that.
I personally use c++ cgi scripts to generate all pages, as I need to do some computationally expensive crunching as well. Why learn a dodgy scripting language when you know how to do it properly anyway ? As soon as you need to do something different or slightly complex all these scripting languages start to become painfull and you need to start augmenting them anyway.
I realise that I am not a cool web developer, and there are potential security problems with using compiled languages, but this works well for me.
Alex
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
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.
I've used PHP, Perl, Ruby and Python (in that order) and I can confirm that Python is in fact cleaner. One of the reasons being it's spartan syntax. It's one of the goals of the language. :)
PHP is just ugly, (see grandparent) Perl and Ruby are quite fun and share the same philosophy (see TIMTOWTDI) where Python is just the opposite (although fun too).
Python and Ruby also share their deep roots in clean object orientation, where Perl's OO syntax is - though bolted on - very flexible and even more TIMTOWTDI than Ruby's.
Just to set things straight, I really like Perl, Ruby and Python, though I can confirm that developing web applications with Django is bliss.
Meme of the day: I browse "Disable Sigs: Checked". So should you.
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.
And there's a good follow-up 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.
Who said Freedom was Fair?
I've developed a large complex project on an earlier version of TurboGears, with CherryPy/SQLObject/Kid, and I love it.
TurboGears is quite modular, and the newer modules are even better: SQLAlchemy instead of SQLObject (database interface), and Genshi instead of Kid (templating system).
-Don
Take a look and feel free: http://www.PieMenu.com
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
All the posts I've seen so far complain about RoR's scalability. These people have obviously not worked with RoR because, while scalability might be an issue, if they'd really worked with RoR, they would know that DEPLOYMENT is what kills rails.
I jumped on the RoR bandwagon full bore and have been developing my app for over 1 year. The Ruby language is awesome and the framework takes the messiness out of web development. When I look at PHP code now I was to puke. With that said, I can deploy a PHP application is seconds...literally. Rails on the other hand, has had me working almost full time for 3 weeks trying to get a fucking test (not production...test) server up and running. It is completely fucking ridiculous to get a server set up that you could seriously test with or, God forbid, move into production.
I've been a Systems Admin for over 7 years and a programmer for 6 years and using Linux for at least 8 years so I'm no newbie or idiot. I've tried setting up everything manually as well as using Capistrano and Capistrano/Deprec and still haven't had success getting a server setup.
It is unbelievable how many crazy little nuances and bizarre configuration parameters you will encounter. In a short period of time you are just copying and pasting any random crap someone posted on the net that claims to have a working server. I've followed countless tutorials TO THE LETTER and this shit still doesn't work.
I even purchased the "Deploying Rails Applications" book from Pragmatic Programmers and STILL CAN'T FUCKING GET SOMETHING DEPLOYED!!! Possibly the worst written book ever and claims to give you everything you need to get the Rails stack set up on Ubuntu Dapper Drake and has almost zero setup commands. What a load of crap. Anyone could have written this book since he just lifted it all from internet posts. Good job asshole, thanks for nothing.
You know what happens to people who can successfully set up a Rails application? They start a fucking hosting company and make a shitload of money because hardly anyone else can do it. EngineYard, SliceHost, and RailsMachine are all examples of Rails programmers who started hosting companies because they actually made something work. It really just shouldn't be that hard.
Maybe someday Rails will be easy to deploy, but right now it is a fucking nightmare. It totally ruins all of the great things about Ruby and Rails. I'm starting to think it's all a conspiracy and Rails was just some kind of carrot to lure us all into purchasing expensive hosting.
The hype about Rails' faster development time is true right up until implementation and then it's a load of shit. Implementing a PHP app is like 2nd grade math, whereas implementing a Rails app is like quantum physics.
I've never been so fucking frustrated about anything computer related in all my life. If you don't have a high tolerance for wading through tons of bullshit, then I don't recommend trying to implement a Rails app at this time.
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.
Use Deprec (www.deprec.org I think) on a clean Ubuntu install. Seriously, when I found it it was almost a religious experience (and we're talking Baptist-esque rolling in the aisles and PRAISE HIM! OH! religion here).
Help poke pirates in the eyepatch, arr.