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