Rails/Django comparison synopsis (a BIG summary)

[Jeff Rodenburg]

For summarization, I've added two of the responses below.  Very well articulated, thanks for the insight.  I appreciate the clear thought on distinctions between the two without some form of java-versus-dotnet war of words.

Some additional observations from a veteran dev that's a newcomer to both of these frameworks:

- Rails deployment vs. Django deployment: Django seems to have a strong plus in this column, while Rails has a real question mark.  Apache2/Mongrel is the current preferred situation, but it's more than a work in progress.  I've been exposed to a Rails deployment recently to gain my modest background with it.  From a deployment basis, Rails has unfinished business.  Thank goodness Django can run under mod_python, makes me much more comfortable.
- My perception on documentation is just that: perception.  The Rails community has the Agile/Pragmatic books to go by, which I think makes it stand out right now.  The hand-authored stuff on their site is suspect, though some of the setup/deployment notes are decent.  If I had a suggestion for the Django crowd, it would be to play up the documentation more so that someone like myself could grok the system a bit better on discovery.
- V2.0 integration: this is a generic label I give any site/project/application that morphs after the first incantation.  I would certainly classify Rails in the monolithic mentality, which is surprising given what's advertised.  It's been my experience that a system of size never avoided an iteration where you were faced with accessing/modifying data outside the original constructs, i.e a separate data layer.  I'm not sure how this fits into the Django structure, but the Rails provisions for integration are non-existent.
- The template structure (which I wasn't aware of yet) is a biggie for me.  We've already seen the presentation tie-in on the template side.  Maybe it's simply a matter of preference, but I like the fact that Django keeps the view separate from the template.

If I sound biased to Django, it's partially due to my preference for Python but also due to my disdain for the Rails jihad that seems to be swelling.  As a complete aside, I'm from the midwest.  How can I not cheer for something out of Lawrence, KS?  ;-)

Thanks all for your responses, this helps me immensely.

cheers,
jeff r.

On 9/11/06, Jeff Rodenburg <jeff.ro...@gmail.com > wrote:

I'm trying to get some education on rather quick order and was looking for feedback from the Django side of the equation.

I've seen a bit of comparison in public forums of Rails and Django.  I'm trying to eval these things from a higher level, or one might call "management" perspective.  (No, I'm not management; I just work for them.  ;-) )

On observation, the frameworks seem rather similar with subtle but key differences, i.e. interpretation of the MVC terminology and structure.  On a quick-read basis, Rails seems to have an advantage of a lot of documentation, more publicity (the Hanson kid sure knows how to work a crowd) and a nice IDE in RadRails.

My question: how would you (you = someone with solid Django background) characterize similarities and differences with Rails?

cheers,
jeff r.

From: Sean Schertell <se...@datafly.net>:
I defected to Django from Rails and so far I'm loving it.

But it really depends on what you need to do. If you're creating a
single monolithic application, Rails is pretty sweet. I did a giant
invoicing/accounting application for an insurance company in Rails.
It handles tens of thousand of members and processes over a million
dollars in transactions per month through an excruciatingly
convoluted billing process. In my opinion, Rails is perfect for this
kind of thing. I'm sure I could have accomplished the same thing with
Django, but Rails just feels a little better geared to this type of
thing -- single, large applications. The built-in ajaxy stuff came in
very handy too. And the Ruby syntax is a real pleasure to work with
(although I'm definitely warming to Python).

But here's where Rails falls down in my opinion, and the reason why I
switched:

(1) Rails apps aren't portable. At all. Not even a little.
Personally, I don't spend most of my time building billing apps for
insurance co's. I mostly build web sites with little apps in them
such as a photo gallery, a blog, a shopping cart. With Django you can
build an app, put it on the server somewhere, and for as many sites
(projects) as you like you can pull in that app, skin it and use it.
With Rails, there's no concept of 'apps' which can be imported into
'projects'. There's just this one big monolithic app which *is* your
project. For website development, this sucks.

(2) Rails apps are a little flaky to deploy. I hear Apache2/Mongrel
is well on the way to solving this. But the standard method of
deploying Rails apps has been using Lighttpd with FastCGI proxied
through Apache. Kind of convoluted and sometimes the FastCGI
processes go nuts and eat up all your resources until you hunt down
and kill each process. Typical Django deployment uses Apache/
mod_python. It's fast and stable and easy to deploy.

(3) Documentation!!! I'm surprised that you mentioned that as a
benefit of Rails. That's one of the very few things that I found
downright annoying about Rails. The docs just aren't there. Sure you
can google up some tutorials or buy the Agile book (which is
excellent by the way). But the actual documentation on the Rails site
is horrible. Mostly user submitted wiki stuff -- some of it is
outdated or just wrong, and there are gaping holes too. The Django
docs are one of things that drew me in right away. Shopping for an
alternative to Rails, when I saw the documentation section of the
Django site, it was like a breath of fresh air. Ahhhh.... now *this*
is what documentation should be :-)

Now the flip-side:

There are a couple things I've found in Django that are not so great.

(1) The admin section is assumed. The admin section is unbelievably
cool when it meets 100% of your needs. But  if you decide for
whatever reason that you wanna do your own custom admin section,
prepare to endure some funkiness. For example, basic authentication.
You can use the bundled auth system, but then you're required to use
hard-coded urls for your login/logout pages. Don't like those urls?
Well then, you're gonna have to write you own authentication system
from scratch. I've found this to be the case for a lot of stuff.
Django gives you some stuff for free, but it's not as flexible as I'd
hoped. And writing your own from scratch feels like more work to me
than it did in Rails (for example the auth system).

(2) No ajaxy stuff. There's nothing stopping you from using prototype
or dojo or whatever. But I have to admit that I do miss the Rails way
of doing it where using ajax isn't really any harder than not using it.

One final point about fit and finish: Probably the biggest surprise
for me coming to Django is how well-polished the framework is. Rails
and Django are really equals in this department I think. To be
honest, I had expected to find Django a little undercooked in some
areas, but it's not the case at all. It's very solid and well-
documented and it works very very well. The community is great too.
Django is very much on par with Rails in terms of polish.


From: Russell Keith-Magee <freakb...@gmail.com>

Disclaimer: I'm a Django developer; I looked at Rails before I got
involved with Django, and I occasionally 'peek over the fenct', but I
don't speak from a position of extensive experience with Rails. I may
have some Rails points wrong, so anyone feel free to correct me.

You are correct in saying that Rails and Django are very similar. The
Snakes vs Rubies event last year confirmed that both Django and Rails
have similar goals - they are out there to make rapid web application
development as easy as possible, attempting to make the common stuff
trivial and the hard stuff easy. The constantly reloading webserver,
minimal bootstrapping to get to 'hello world', and use of languages
with strong meta-class and introspection capabilities are features
common to both frameworks.

I'm sure others will have other opinions, but here's my take on the
differences.

1) (Obviously) Python/Ruby. This shouldn't be a serious reason to
choose either tool, but it is a key difference.

2) Database design. Rails starts with you defining an SQL table in
your database, then writing Rails models that reflect the state of the
SQL. If you change your table on the database, you change your model
to reflect it. Django is write-once - you define a Django model, and
Django creates the SQL table that reflects that model. There is a
Google SOC project currently tackling the issue of migrating schema
changes over time.

Which is better? I prefer Django's approach, because for a new
project, I don't need to write the same definition twice (I've written
enough C++ code in my life to want to avoid doing this ever again :-).
I've seen many an argument that the Rails approach is better for
integration with legacy databases. I haven't had to do this myself,
but Django can introspect a databse, provide suggested model
definitions, and skip the table creation step if neccessary.

3) The Admin view. Rails has scaffolding, but you still need to write
at least _some_ template code to get a management interface. Every
Django application has a management interface out-of-the-box. There
are add on packages for Rails that add similar functionality, but they
aren't built in.

For me, this was a big one. End users shoud almost NEVER see the
management interface. But in terms of getting a project off the ground
- establishing confidence that your models are correct, poking in some
test data to validate some view that you have under development - I
have found the Admin view to be invaluable. Plus, all the parts that
the admin view uses are also available to end users to drop into their
own views.

4) Template philosophy. Rails templates are essentially Ruby code -
very programmable, legal in ruby->legal in template. Django templates
are very specifically NOT programmable.

Personally, I like the Django way, because it encourages (nay -
enforces) separation of view logic from representation. This makes it
trivial to replace templates down the line, or do per-user skinning,
or per-media views. You can do the same thing in Rails, but it's a lot
easier to get trapped putting logic into your templates which can't be
pulled out later.

5) Documentation. You seem to throw the favour to Ruby on this one,
but I'm not in 100% agreement. I'll agree that there is a lot more
_volume_ of documentation; a few books, etc. However, IMHO there is
also a lot of crap in there. A lot of 'a wiki will solve all our
documentation problems'. At one point, I tried to work out how Rails
handled aggregate clauses. I gave up looking in the documentation for
the answer.

There's also the issue of flavor. I've tried reading Rails and Ruby
documention several times, and I just don't like the way it 'tastes'.
"Why's Poignant guide" is a good example; it's cute postmodernism (and
a great piece of art), but it doesn't grok with my way of wrapping my
head around a new language.

Django has less volume of documentation, but what is there is
generally gold. It's pretty well organised, and the flavour is
consistently one of 'professional with a quirky sense of humor',
rather than 'comedian with a quirk sense of professionalism'. There is
a lot to be said for having the project lead being a Journalism major
:-)

As for rumours - I have heard some commentators (admittedly, mostly
J2EE, PHP and .NET junkies) question the scalability of Rails,
especially considering their HTTP stack (Lighttpd/FastCGI, IIRC).
Django's default deployment is throught Apache, so any Apache load
balancing trick works for Django sites. Django also has very
sophisticated caching frameworks which come in handy on high volume
sites. Django sites have survived several slashdottings over the years
on relatively modest hardware. However, take this last point with a
grain of salt - I can't comment on the validity of this issue for
Rails - my deployment experience is limited to Django.

Anyway, enough waffling. At the end of the day, they are both fine
tools. I like Django - to me, it's a clean fit for my mental model;
but Rails doesn't get the press it does _purely_ because of DHH's
marketing genius. YMMV.

[Jay]

I also agree with documentation in Django. I'm amazed when I began
browsing for help files in the site. I did not expect that the docs
there are massive. It covers a lot of WHY did this happen and HOW to
make it happen. The help for Django has more ham compared to ruby on
rails. I think if you compile all the docs in djangoproject, throw in
additional examples and make it a PDF, it is even better than the ruby
on rails book that is out in the market right now.

BTW, I am a Rails-turned-to-Django user simply because of these
reasons: Python, Performance and Productivity. I think there is no need
to go in detail. Productivity can be argued but I just find the Python
syntax more readable compared to Ruby (I came from a dot net
development background).