Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Posted by Luciano Ramalho on Nov 16, 2006 11:35 AM
Thanks to a couple of web developers, we now have a fairly objective comparison of Ruby on Rails and Python's Django framework. Ben Askins and Alan Green jointly specified and then developed parallel implementations of a simple web app for sharing book reviews. Their report and source code are available online. They conclude that neither framework is clearly superior to the other, so it's probably best to stick with the one written in the language of your choice. There are, however some important caveats which make the decision a bit more complicated.
No need to introduce Ruby on Rails here, but it's worth noting that Django stands out in the Python world for two reasons: Google has clearly put its weight behind it, and Guido van Rossum, Python's benevolent dictator, has taken the very unusual step of blessing it instead of other equally well regarded choices. Also, Alan and Ben point out that "Django [...] does not ape Ruby on Rails".
When comparing line counts between the web apps implemented by the authors, Rails beats Django with 4% less lines overall. Although the templates in Django are much more verbose, that framework provides an admin interface almost for free so they actually wrote less Python than Ruby code. For development time they clocked 25:45 hours for the Rails implementation, compared to 16:36 in Django. Of course we can't tell whether Ben or Alan code faster, but again they attribute the difference to the need to code admin forms in Rails, while Django generated them from just a few hints in the model. The authors recommend investigating Rails plug-ins such as AutoAdmin and Streamlined to compensate for that.
The paper points out that Rails makes using AJAX easier with RJS and the integrated JavaScript libraries, while Django includes JSON functions, but leaves all JavaScript coding and even the choice of client-side libraries to the developer. JavaScript wizards may prefer Django's hands-off approach, but everybody else benefits from the built-in AJAX support in Rails.
On the other hand, they note the Python framework offers better infrastructure for internationalization thanks to native unicode support and gettext message substitution, allowing for multi-lingual sites with localised responses to individual HTTP requests.
A major advantage for Rails is the migrations mechanism which facilitates experimentation and evolution of the data model, even for apps already in production. Django has nothing of the sort. If Alan and Ben had omitted the migrations from the line count, their own numbers show that the Ruby and Python code would be about the same size and, after adding the templates, the Rails solution would have 15% less lines of code than the Django one, even while providing custom admin pages. So here the authors compared apples to (non-existent) oranges, with a bias which favored Django.
Mr. Green and Mr. Askins wrap it up diplomatically: "While choosing between these two frameworks may be difficult, the good news is that either framework is a good choice a team wishing to develop a web application." If advanced internationalization is a requirement for you, their analysis suggests Django is the best choice. Those who don't need that but want ready-to-use AJAX functionality, anticipate lots of different templates and crave the comfort of database migrations will benefit most from Ruby on Rails.
Software Quality Survival Guide
IBM Web 2.0 Developer eKit: Free Tutorials, Webcasts, Whitepapers
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Ruby VMs, Scaling Rails, YellowPages.com on Rails, Merb @ QCon SF Nov 19-21
If Alan and Ben had omitted the migrations from the line count, their own numbers show that the Ruby and Python code would be about the same size
There was only a 4% difference anyway. Surely that is "about the same size"?
There was only a 4% difference anyway. Surely that is "about the same size"?
When I mentioned Ruby and Python code in the paragraph about migrations I was excluding the code in the templates. Since there were about 40% more lines in the Django templates, if the line count for model and controllers were about the same, that would reveal a significant advantage to Rails. The difference would be close to 15% less code overall for the Rails app with database migrations and hand-made admin pages, compared to a Django app without migrations and auto-generated admin forms, according to the numbers quoted in the original comparison.
The difference would be close to 15% less code overall for the Rails app with database migrations and hand-made admin pages, compared to a Django app without migrations and auto-generated admin forms, according to the numbers quoted in the original comparison.
I made a mistake in my previous comment: the difference would be close to 15% less code overall for the Rails app *without migrations* but with hand-made admin pages, compared to a Django app with auto-generated admin forms.
Hey, where's the comparisons to the Java Pet Store and .NET Pet Store? (Just kidding.)
That's an excellent comparison and one of the few (if not the only) that kept its objectiveness. And the conclusions should be taken by each project lead when deciding which one to use for a new project. Congrats and thanks to Ben Askins and Alan Green for driving it and making their results and code available. ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. Co-founder of InfoQ.com
Not quite a .NET Per store but here is something for .NET Architecting Toronto.com. ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. Co-founder of InfoQ.com
I don't think such a study proves anything if it leaves out one of the most important aspects of Web frameworks: future maintainance. Here is an idea: let these two applications sleep for six months and make sure that none of the programmers touches them. Then in six months, ask them to make a fairly substantial and disruptive change and see how long it takes them, and how much of their initial design they have to change. -- Cedric TestNG
Good idea Cedric. We'd also like to introduce internationalisation and AJAX requirements into the spec. Given that these are purported strengths of Django and Rails respectively, it should draw out more points of comparison. However, we had a constraint to complete the comparison in time for OSDC. Perhaps next year we'll look at a more in depth comparison. cheers, Ben -- teamaskins.net
Great suggestion Cedric! However, considering that the first steps look to be completely unbiased it is a good start :-). ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. Co-founder of InfoQ.com
And how about some reporting? In that 6-months-later cycle, they should have to hook in a reporting package against their DB schema. Is there any RI in the schema to help a reporting tool figure out the structure?
In my experience line counts depend mostly on availability of suitable libraries and on software design decisions. That difference can easily be in the area of several hundered percent. And there's one thing missing from a simplistic comparison like this: Both Python and Ruby are awfully slow. So for many projects there will be a need to write parts of the code in C/C++. Therefore, the quality of C/C++ interfaces, including platform/compiler considerations, should be part of any comparison.
That's more than just a slight exaggeration. Who's going to bet against C-extensions making up a statistically insignificant portion of Rails sites? It's probably also a pretty safe bet that 99.9% of deployed Rails sites don't use any custom extensions. The parts that would need to be in C (like Mongrel and the Core libs) already are. The rest is just a bit of url to object/method routing, templating, and O/R Mappin'.
Well, if that is indeed the case it merely shows that, today, rails is used for a very limited range of applications. If that is to change, there will be a need to productively integrate with something fast. I get the impression that Ruby's C interfaces don't work well (if at all) with modern windows compilers. Python seems to be way ahead there.
Have you even used Rails? What's with the straw-man about usage? Why not look into the actual types of applications deployed with Rails? I've written a C-extension to use the SqlClient namespace from ADO.NET in Rails, and the Ruby interfaces were the least of my problems. They're actually pretty straight-forward. Is the library very portable? No. But that has nothing to do with Ruby and everything to do with writing a C++/CLI extension with VS2K5. If the libraries you're bridging are platform specific, then portability will be an issue. That's not Ruby or Rails specific. What this thread really reveals is the surprising amount of FUD still out there about alternatives to Enterpriseyness. The least you could do could is look into this stuff for yourself, instead of making baseless assumptions and setting up straw-men to knock down. Ruby integrates (with varying degrees of success) with C, C++, .NET, Java, OCaml, Objective-C, and that's just off the top of my head. I'm not here to knock you down. You could probably teach me a lot, but frankly I don't understand why you feel compelled to criticize something you obviously haven't investigated even superficially yourself. If we stick to the facts I think we'll all benefit.
As this article points out - a good majority of the choice comes down to personal preference. For me - a good majority of that personal preference comes in the form of what I have confidence in. I'd like to have confidence in ruby/rails. But right now - I do NOT have that confidence, and it comes from exactly what you suggested. Looking at the types of applications that have been deployed using rails. Has anyone ever stopped to think that maybe some of us are concerned about enterpriseyness for a reason? I mean, I hear DHH in a recent interview talk about 500,000 users (across 5 different applications) - and it doesn't impress me. One of my previous jobs was with a company pulling 7mil+ registered users and well well over 100,000,000 pageviews a month, and that's just on the main .com site. Sorry - but that puts anything that 37signals has talked about publically to shame. Not trying to put anybody down here, or anything like that - but some of us DO have to think about bigger things, and have some serious questions - and *need* to have a good dose of skepticism. If 99% of applications never have to use extensions to make up for bottle necks (which by the way is a huge recomendation coming out of 37signals right now to handle heavy lifting) - then tell me where the line is for that 1%? Tell me what the limitations are. What you call FUD - some of us simply call "work". We're constantly hearing about how ruby isn't about the enterprise, it's about making developers happy. That it's performance issues aren't real issues because it's "fast enough for most applications". Well, where is that line where it's not fast enough anymore? When we raise that question, and we try to bring up the issues - we get slammed for not believing. If it's fast enough for most applications - but even campfire has had to drop down to C to make up performance gaps - where does that leave me with 14x the userbase on a single site than all of 37signals apps combined? Some of us really want to go out on the limb with you guys, but given the circumstances of what we're dealing with - "developer happyness" is not enough to make that leap of faith. When you look at *those* facts, suddenly your straw men aren't so flimsy anymore. I don't mean to be such a prick about all this stuff, and I apologize if I come off a bit harsh - but please understand my frustration when threads like this pop up. I've spent the last several months looking for a way to justify the leap, and this thread pretty much sums up the total of what i've found. Excuse me if i'm not falling all over myself to jump on your bandwagon.
I am really happy to see that people are finally starting to do real-world analysis and comparison to sort through all the different opinions floating around. The more of this we see, the better all our jobs are.
Thanks so much for this! This is exactly what I was looking for mirc mırc eski mirc kameralı mirc irc komutları mirc indir mirc indir mırc indir mirc mırc mirc yükle mirc download islami sohbet dini sohbet islami site islami chat kelebek kelebek script kelebekscript kelebek.gen.tr kelebek.com kameralı mirc indir kameralı mirc kameralı sohbet chat chat yap chat sohbet chatsohbet çet çet sohbet çet yap sohbet kanalları izmir sohbet kanalları sohbet odaları aşk sohbet odaları chat odaları soru cevap sevgili sevgili bul arkadaş arkadaş ara arkadaş bul arkadaşlık bedava sohbet arkadaşlık sitesi arkadaşlık siteleri partner erkek arkadaş bayan arkadaş oto araba mp3 astroloji zoydak nedir cep telefonları gazete marifetname bedava domain ücretsiz domain bayii parça kontör bayiliği bayii radyo dinle
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
17 comments
Reply