Rails and Django Compared
By Ryan Tomayko under Then they laugh at you..., Rails v. Django on 17. July 2005Once Django is launched-launched, I’ll be comparing various aspects of it with Ruby on Rails. I plan on diving deep into the two frameworks so instead of one large post, I’m going to make this a running series.
While I’m primarily a Python coder, I’ve been dabbling with Ruby for about a year and have a couple of apps under my belt with Rails. They are admittedly simple apps but what isn’t with Rails? I’ve also logged 70-80 hours against a Python clone of Rails’ excellent implementation of Active Record, which put me pretty deep into the internals of that piece.
I am not a Python zealot. And, to be honest, I’m floating between the two languages as my primary. What I’m trying to say is that my interest is in exploring these two frameworks objectively and extending my understanding of each, not advocating one over the other. I will include personal thoughts on design and may favor one or the other at this level but I will not be concluding the series with a recommendation for either because, frankly, I already know which I’d recommend at present and it has nothing to do with technical qualities (hint: it has everything to do with this).
That being said, I can recommend that if you are building systems that require the complexity of a full-stack web framework (i.e. PHP, CGI won’t cut it) and you are currently using something other than one of these two frameworks in any language (including Java and .NET) on any platform, that you move swiftly to adopt either if possible. If there is something barring you from making that switch, well, where’s your patch? Make it happen.
I realize that many in the Python community have already grown comfortable with an existing framework (or more likely, have written their own, like myself) and that’s fine as there are some competent frameworks out there. But it has become apparent that Django will be growing a large community of contributors and that’s something no current Python web framework of this kind can boast.
As I write this, there are 30 people idling in #django on irc.freenode.net on a Sunday morning, two days after the none-launch; there’s been 409 bookmarks on del.icio.us. Granted this is all very much driven by hype right now as there hasn’t been any real experience with the framework, excepting the maintainers, but the outlook for a large community to finally coalesce around a single set of tools and conventions is promising.
I also want to mention that I spent some time talking to the Django maintainers last night and they’ve convinced me that the Rails comparisons, while unavoidable, may be somewhat premature. Although Django has many of the same traits as Rails, it wasn’t built as an all out clone and may appeal to a slightly different set of requirements. Time will tell, of course, but as of right now the similarities are a huge part of what’s driving interest in Django and there’s a good reason for that - Rails got a ton right.
Still, “because it’s in Rails” is unlikely to be considered sufficient justification for Django feature requests. That’s a sure way of creating a Bride of Frankenstein framework and I’m pleased to see the maintainers have a strong sense of this. Django is likely to follow many of the same paths as Rails but that’s because they were both designed under real life circumstances with similarly excellent philosophy.
Before I wrap this up, I’d like to echo the sentiments of one Rails supporter in his comments on Django:
I hope Rails learns to play with Django and they’ll not smite each other (if not friends, don’t be enemies). The world is big enough. A combined message from different camps will be more resounding than any one camp trying to say he is the bestest - and coming off as naive or clueless.
Indeed.
(warning: stomach wrenching, KUM BAI AH, everyone-hold-hands type stuff imminent)
The Ruby, Python, Perl, and PHP communities must understand the immense opportunities that await them should they accept that they share much more in common than not and that a unified front would go a long way in tearing down the barriers that have kept these technologies out of the mainstream. The amount of positive impact these disruptive technologies could have on existing forms of business and social interaction in general are limited only by our ability to tell the story.
Feeds for the series:
Fredrik:
Every framework claim to be “on rails” these days. The most ridicolous i’ve seen is MonoRails. They begin their tutorial with doing J2EE-style XML situps. Can you say “missing the point”? They all seem to think that it’s all about scaffolding (it’s not).
Anyway, Django seem to be somewhat guilty of this as well, with a slogan like “It’s just not scaffoldning, it’s the whole house”. It seems that Django doesn’t use the “generate-and-modify” paradigm but focuses on providing a runtime-generated CRUD interface that can only modified by CSS.
This is excellent for some type of apps, e.g. where only the “R” part is public but could be a disadvantage in other types. There doesn’t seem to be any middle ground between the generic CRUD interface and a fully custom one. Or am i missing something? (I have only looked at the docs).
I’m glad that Django doesn’t try to clone Rails feature-by-feature though as i think that would ultimately lead to an inferior framework. There is definitely room for both, and the competition is the “static enterprise” guys just as you say.
Lastly i would just like to say thank you for Kid (the only templating language that makes sense ™). I’m using it at work for an in-house app and it simply rocks, simplicity rocks :)
comment at 17. July 2005
Ryan Tomayko:
“The most ridicolous i’ve seen is MonoRails. They begin their tutorial with doing J2EE-style XML situps. Can you say “missing the point”? They all seem to think that it’s all about scaffolding (it’s not).”
Agreed. The Java/C# guys need to accept that their languages are crippled in ways that make DRY and significant code reduction impossible. The Java world at least is beginning to come to grips with this. The initial round of bashing suggested that Java was absolutely capable of Railsish idioms but the results came no where close. Now, smart Java people are beginning to realize that moving to more agile languages are going to be necessary.
That’s why I think we need to get our shit together. We’re seeing an influx of Java/.NET programmers and we need to be sure they have somewhere to land.
comment at 17. July 2005
David Heinemeier Hansson:
I chuckled at “it’s the whole house” too. But at the same time, I think its cool. They extracted a solution to a problem they were having: Creating admin interfaces for content sites. Doing the whole house is a great thing in those cases.
Rails went with scaffolding because it was never meant to be anything but a starting point and a learning tool. Something you molded into the application you were actually after.
But it’s all in good sport. The django guys obviously needed to get a few jabs in at “The One To Beat” and especially at a Python meeting. I would have been disappointed if they hadn’t try to come up with a hook like that ;)
It’s a cool example too because it shows the difference of origin and focus. With django coming out of the custom CMS world (with features great for that) and Rails coming from the more generic application world (with features great for that).
And I agree on the overarching vision. It’s about getting the bottom of the productivity barrel to see the top of the pop.
comment at 17. July 2005
Ryan Tomayko:
“With django coming out of the custom CMS world (with features great for that) and Rails coming from the more generic application world (with features great for that).”
That’s a difference I’ve noticed as well. It’s interesting no one is comparing Django to Plone, no?
comment at 17. July 2005
Jacob Kaplan-Moss:
I gotta say — as one of the people who made a few jabs at Rails on the Django site — said jabs are certainly meant much more as jokes than seriously. Fact is, Rails is rather incredible, and the competition between Djagno and Ruby — real or perceived, friendly or not — can only serve to improve both frameworks.
David: you’re completely right about Django coming out of the custom CMS world as opposed to the web-app world; that’s where I think the two have the most to learn from each other. Django could be too heavyweight for something like Basecamp, but I’d be out of a job if I had to manage newspaper sites (and the associated staff and workflow issues) with Rails. That’s been the real reason I personally have been trying (mostly unsucessfully) the “Django == Python on Rails” meme; by setting up a false dichotomy is does a disservice to the different problems web developers face.
Maybe we could have a “dynamic web frameworks” summit where we can bring together Rails-ers, Djangoists, and PHP-heads and all kick around cool ideas…
comment at 18. July 2005
M. Edward Borasky:
“warning: stomach wrenching, KUM BAI AH, everyone-hold-hands type stuff imminent)
“The Ruby, Python, Perl, and PHP communities must understand the immense opportunities that await them should they accept that they share much more in common than not and that a unified front would go a long way in tearing down the barriers that have kept these technologies out of the mainstream. The amount of positive impact these disruptive technologies could have on existing forms of business and social interaction in general are limited only by our ability to tell the story.”
I just discovered Ruby on Rails a week or so ago. To put this in context, I’ve been programming for 43 years, mostly scientific applications and operating systems. I’ve never bothered to learn Ruby, Python or PHP, but I did learn Perl back in the days when Perl 5 was a gleam in Larry Wall’s eye. I agree that “a unified front” would go a long way, but the fact remains that if it weren’t for Rails and all the associated hype, I probably wouldn’t bother to learn Ruby. I have Perl, and R, and Lisp, and Fortran, and Forth … do I really need to learn another language?
In any event, I have decided to learn Ruby only because of Rails — because I want to develop web applications. If there’s an equivalent framework available in Perl or Lisp or even Forth, I’m all ears — I really don’t want to learn another language.
comment at 18. July 2005
Ryan Tomayko:
Well, I believe there are at least 2 Rails clones in Perl and I once overheard that,
“Lisp on Rails will be called Railth,” — whytheluckystiff
If I were you, I would unlearn 20-30 of those languages and pick up Ruby anyway.
comment at 18. July 2005
Viva La Chipperfish » Comparing Django/Rails to Plone:
[…] In response to this comment to this blog post: […]
pingback at 18. July 2005
Jason Huggins:
Okay, I’ll give it a try. :-)
(Blogged here: http://www.jrandolph.com/blog/?p=9)
I have production sites in Plone and have been working with Plone full-time for 2 years. But I’m happy and eager to flirt with other frameworks, and I’m very eager to start playing Django.
Plone is a CMS that is heavily customizable (that’s what it’s marketed as, at least). Django is a generic app framework that you can use to build a CMS. The difference might appear to be mere semantics, but I don’t think so. Plone provides tons of functionality, but also expects tons of loyalty and dedication from a developer to take it all in and become productive. Plone specifically decided to not market itself as a generic app dev framework, unlike Rails or Django. Plone is not generic enough to please your average PHP or Rails dev. However, if you’re willing to do things the “Plone Way” Plone is a pretty decent framework to write custom stuff with.
Okay, time for more specific comparisons:
Data mapping to relational databases. Plone has some basic support for relational databases via ZSQL Methods, Archetypes, and APE, but these are not as straight-forward to work with as Rails’ Active Record, Ian Bicking’s SQLObject, or Django’s Model API. This situation is changing in Zope/Plone land thanks to cool projects like Hornet and sqlos. However, Rails and Django are way ahead of Plone when it comes to ORM. Data mapping to my Oracle databases is my biggest frustration with Plone and where I most often bump into those “fighting the framework” moments. That frustration has led me to evaluate alternatives like Rails, CherryPy+SQLObject, and now Django. I haven’t tried Plone+Hornet, yet… so we’ll see how that goes.
In addition to the generated HTML UI, Plone gives you WebDAV, FTP, and XML-RPC access to most URLS/objects “for free”. This is often handy, and doesn’t look like it is there in Django, yet.
With Plone, the UI work is done for you, including CRUD forms for the objects you create and other UI forms like login, password changing, and site navigation. And you can customize it when you need to, without too much pain. Rails does provide scaffolding, but it is only a starting point, not a useable “deployable” solution. (This was on purpose and is okay… if that’s what you need/want.)
From what I’ve seen of Django, Django provides a more “ready for production” UI than Rails, and I like that. I’ll be playing with Django to see how much of the auto-generated admin CRUD forms in Django I can present as data entry forms to users, instead. It looks like Django sits somewhere between Rails and Plone in the auto-UI-creation department.
Process workflow and security granularity (roles, permissions, ACL and all the combinations and intersections) - Plones beats Rails and Django. It appears you are on your own when it comes to securing your Rails app. Django is somwhere in the middle between Plone and Rails on this.
Internationalization - Plone puts in a huge focus on multi-lingual translations and internationalization support. Plone wins here because so few other frameworks care as much as the Plone developers do about this.
Accessibility - AJAX is cool, but making sites accessible to the blind is still important. The Plone devs take a more cautious approach to adding fancy JavaScript bells and whistles to the UI. I have a hunch (but this is only a hunch) that Django is taking the same cautious approach as Plone when it comes to AJAX support. I can’t help but think that Rails is hyping AJAX support at the expense of accessibility concerns.
Personally, I don’t require the internationalization or accessibility features of Plone, but I can understand there’s a market need for them. However, I do appreciate and require the crazy security options that are made available to me in Plone. Neither Django, nor Rails, yet match Plone in the security options department. But I’ll be watching that space closely.
comment at 18. July 2005
rvr:
M. Edward Borasky: You should take a look to Catalyst (Perl). O’Reilly published an article about it.
comment at 18. July 2005
Jeff Shell:
I’m surprised at all of the attention Django is getting here while Subway is not. Subway aims to provide a Rails-style stack while using many “existing Python web libraries and tools”. It uses CherryPy to serve, it uses SQLObject for object-relational mapping, it uses Cheetah as the default tool for templates, and on and on. I don’t know if it does full scaffolding, but it does seem to better apply new Python meta-programming technologies better than what I’ve seen of the Django examples.
The use of meta-programming is something that I find really impressive about Rails, particularly ActiveRecord. It makes the bridging between the object and relational worlds a bit easier fit within the language (Ruby).
I think there are Subway examples that use CherryFlow, a system that runs on Stackless Python to do continuations based web development ala Seaside.
Personally, I think it’s silly that the Python web community seems so hell-bent on trying to copy and do a “pythonic” implementation of the popular system of the day. There are numerous Servlet copies, numerous JSP/ASP copies, and now a growing multitude of Rails copies. When I started doing web development with Python, everyone was trying to figure out how to compete with Perl.
So I’m going to stick with Zope 3 and give applause to Nevow, Quixote, and CherryPy for at least being different.
comment at 18. July 2005
Simon Willison:
The reason Django is getting more attention than Subway right now (apart from the new-ness factor) is simple: Django, like Rails, was extracted from existing applications. It’s tried and tested - a bunch of reasonably high traffic sites have been running Django for nearly two years. I haven’t year heard of any “real” sites running Subway - they started with the framework.
comment at 18. July 2005
Matthew Marshall:
Jeff Shell:
Something you need to note, is that while subway is an attempt to copy Rails, Django is not. In fact, I believe Django pre-dates Rails.
MWM
comment at 18. July 2005
DougHolton:
More FUD about .NET and Mono from Fredrik Lundh, who makes money from python software.
Yes, MonoRail (for .NET & Mono) and Trails (for Java and the Java VM) are nowhere near as easy to use as Ruby on Rails or Django. But they are the only options, and there is hope to making them much much easier to use than even Django by combining them with new languages for .NET and JVM that have a lot more flexibility than java or C#, such as groovy (http://groovy.codehaus.org/) and boo (http://boo.codehaus.org/) for .NET/Mono and IronPython (now owned by Microsoft).
comment at 20. July 2005
Ryan Tomayko:
Doug: while I can’t be sure, I don’t think that was Fredrik Lundh. My understanding of Lundh’s general development philosophy is that he’s decidedly anti-framework, and there are a whole lot of other Fredriks in the world besides.
As for Boo and Groovy, I do hope they work out because I would like nothing more than to see dynamic languages take over the mainstream VMs but I’ve seen little to suggest that they provide the level of quality, performance, or community backing of the C based interpreters.
comment at 21. July 2005
Simon Brunning:
You’re right, Ryan, there’s no way that was the effbot. Nothing like terse enough. ;-)
I really never saw the point in Groovey. What does it promise to deliver that Jython doesn’t already give you?
comment at 21. July 2005
Anonymous:
M. Edward Borasky: BKNR is a Common Lisp Web Application environment.
comment at 21. July 2005
Magpie’s Django / Rails comparison [@lesscode.org]:
[…] As a side note, I had planned to do a series around this but I promised Adrian and Jacob I’d hold off until Django was launched-launched, which I assumed meant 1.0 at the time but that seems a ways off now… I’m not sure Django can get any more launched at this point so I might have to revisit that promise as I’m anxious to get moving on this. […]
pingback at 16. August 2005
Michael:
Subway / Django: The most important reason why Django gets attention and Subway doesn’t is the docs. Django’s isn’t finished but already very usable, Subway’s is just an empty wiki - true to Python web framework tradition.
comment at 17. September 2005
Guy Murphy:
IronPython is faster than CPython, and CPython compatible… what more do you want?… Python under .NET is faster than CPython.
If the Pythonic bit is of interest without the Python lib, then Boo fits the bill very well.
If performance and quality are still of concern to you, then I’d respectfully suggest you might need to update your view of the current state of art past the benchmark Active State set quite some time ago.
comment at 04. December 2005
Django o Ruby On Rails:
[…] Rails and Django Compared […]
pingback at 18. July 2006