

Rails - Django Comparison - raghus
http://www.scribd.com/doc/121814/RailsDjango-Comparison

======
mechanical_fish
On the one hand, you really miss the talk that these slides were attached to.
Browsing the slides by themselves is kind of tedious and lame.

But the split-screen format really drives home the message that Rails and
Django -- apart from a few minor differences that will probably converge over
time -- are _the same thing_ , implemented in different languages. There's
just not a lot in there to hang a flame war on. Emacs vs vi, this isn't.

------
fiaz
Slide 68 indicates latest Rails version is 1.1.6. The document was uploaded on
19 June (I'm guessing 2007). Is this really relevant now?

I will tack on that the framework will not make or break your idea. The
advantage of one framework over another should be weighed in how long it takes
your team to go to market; this translates into asking your development team
(or yourself) what they (or you) can handle in the coming months in
anticipation of the project taking off. Also your code should be done in such
a way that you can ditch whatever framework you currently use for something
better suited for what your future requirements might be.

I will add that I believe TurboGears to be the better platform all around, but
am sticking to Rails because:

1) I like Ruby/Rails

2) I don't have the time/energy to dive into Python/TurboGears

3) I can implement something by myself confidently in Rails RIGHT NOW, as
opposed to a few months down the road after getting comfy with Python (while
at the same time maintaining my day job and OTHER life responsibilities)

------
waldrews
I went with Django because I could read its codebase, but found the Rails
codebase too cryptic. Rails magic, epitomized by the pluralization rules, was
also a turnoff - the prospect of debugging in that world seemed scary.

The case for Django is the clean, modular architecture, making it possible to
split a project into reusable applications. With Rails DHH took a strong anti-
component stance, deciding that it was better to make everything easy to
reimplement. As a result, even common things like the registration gem have
too many integration points. This decision will matter in the long run.

Django has access to all the mature Python libraries, but its ORM is limited.
Pythonic model specification and automatic model validation against the SQL
metadata is great for the DRY philosophy; but there is no migration metaphor
(yet), there's no table inheritance metaphor (yet), and even pessimistic
locking requires a hack (so far). The best hope is an effort under way to make
the Django ORM a wrapper for the infinitely more powerful SqlAlchemy, which
some people use on top of Django anyway, foregoing its data-related tools
including Admin.

And of course Rails is integrated with every concievable Ajax technology,
allowing a hundred ways to implement the <blink> tag.

The Rails community is growing from an influx of ex-PHP scripters, bringing
with them less disciplined coding styles, which the more Perl-like overly-
concise features of Ruby encourage. The RoR environment is going to be the new
Perl - a powerful tool for certain applications, applied far more broadly than
intended, with a CPAN full of one-off solutions for every concievable problem,
but no culture of solidly engineered modules.

------
ess
I wrote my app in Python/Django. My reasons were short:

1\. I wanted to learn python, but was not really interested in ruby 2\. Rails
is too hyped. The problem here is that people pigeonhole you when they hear
that you are a rails developer. If someone ever came to me and told me he was
a rails developer, I would immediately perceive this guy as someone who jumps
on technology bandwagons. The type of guy who listens to top40 charts. 3\.
Django just had a way better argument when it came to performance

and the most important reason of all

4\. When I created a new Django project, it just created 3 files. Rails (when
I tried it) created a bunch of folders and files. People have to understand
simplicity in all its facets to be effective programmers, in my opinion!

------
jjburka
My question would be why did rails' models take so long to do compared to
django. The examples they gave the rails were shorter (granted neither were
complex) I'm going to assume that they have the same number of models (5ish)
so it can't be that.

------
raghus
I especially liked the fact that they did not seem to have any bias going in
or coming out. And, they actually built the same site using both frameworks
and took notes along the way - all in all, very commendable.

------
henning
They're comparable enough that the individual programmer matters much more.

I say pick one, learn it as well as you can, don't worry that you picked "the
wrong framework", and go with it.

------
bprater
Slightly unfair comparison when it comes to admin pages. When it comes time to
modify the Django admin pages to do something the framework doesn't supply, I
bet the graph gets a bit more even, if not in the favor of Rails.

This is true of any framework: the second that you go outside the bounds of
what it was designed to do, you are going to spend lots of time bending it to
your will.

~~~
astrec
Indeed. You can probably infer this is the case when they show the graph with
the admin component removed.

------
jrsims
When Rails and Django compete... we win!

------
tx
What's the _original_ format of this presentation? Why can't I just save it as
a PDF or view as HTML?

------
thomasfl
Good to see some actual experiments with the different frameworks, not just
expert thoughts.

