Django vs Rails
Glenn Tenney
through "Agile Web Development with Rails".
Some quick thoughts... with a couple of questions thrown in...
1. Ok, there IS the Ruby vs Python thing... I'll leave that to some
*other* place for THAT flame fest as I do NOT want that here!
2. In Rails you need to declare your SQL code *and* tell Rails about
your schema, but in Django it's all very nicely put into an object
oriented description in your model. A big win, to me, for Django.
3. Rails supports and integrates well with Ajax. I know that this is
"coming" for Django... sometime "real soon now"... how's it going?
When might it be out?
4. Rails has built-in unit and functional testing support. I don't
know, but I'd venture a guess that few Rails apps actually USE the
built-in testing capabilities, but it *IS* very nice... Is there
anything like that planned for Django?
5. Rails has a book or two already out there -- and already out of
sync with the version of Rails recently released. Django's book is
"in the pipeline" but I doubt it'll be out until 0.92 gets released.
Any other major differences that I missed?
--
Glenn
Adrian Holovaty
> 5. Rails has a book or two already out there -- and already out of
> sync with the version of Rails recently released. Django's book is
> "in the pipeline" but I doubt it'll be out until 0.92 gets released.
Django 0.92 will *definitely* be out before the book comes out.
Possibly Django 1.0 will be out before the book.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
James Bennett
> "coming" for Django... sometime "real soon now"... how's it going?
> When might it be out?
I put in the patch for the initial Django/Dojo mashup (Dojo is the
JavaScript toolkit we're going to ship with Django) just the other
day, and I've had a tarball of a modified Dojo-enabled Django admin
app up for a while.
Note, however, that this is not "AJAX integration" in the sense that
Rails has it; we'll be including Dojo in Django and offering the admin
app as an example of how you can take advantage of it to build useful
JavaScript functionality into your own applications. There's been talk
of a generic Django web-service system which would make it much easier
to do remote JavaScript calls (or programmatic calls from any
language, really), and when that's built in there will undoubtedly be
a JavaScript library included with Django which can take advantage of
it, but I don't think the extreme level of "AJAX integration" in Rails
is something that would feel right in Django.
> 4. Rails has built-in unit and functional testing support. I don't
> know, but I'd venture a guess that few Rails apps actually USE the
> built-in testing capabilities, but it *IS* very nice... Is there
> anything like that planned for Django?
AFAIK Django ships unit tests for all of its own components. Writing
tests for your own applications wouldn't be particularly hard, given
the ease of testing in Python.
> 5. Rails has a book or two already out there -- and already out of
> sync with the version of Rails recently released. Django's book is
> "in the pipeline" but I doubt it'll be out until 0.92 gets released.
While I can't speak for the authors, I'd say it'll be a good long
while after 0.92 is released when the book hits the shelves.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
simonb
by writing a simple little app (voting/wiki/blog etc.) Find which one
fits with you. Also think about how and where it will be
deployed/hosted and how easy/possible that is with the system you
choose. Personally: having written big web apps in PHP I vowed "never
again" and tried RoR, TG, Plone and DG - for me DG feels right.
I wouldn't read too much into the Ajax thing - I'm doing Ajax now just
fine with DJ and Prototype. Also don't assume that because it looks
easy in a screencast, it will be easy when you try it.
You might like to checkout this video from JPL
http://oodt.jpl.nasa.gov/wiki/display/oodt/Home - Click on "Better Web
App Development" - ignore the bit about DJ not supporting i18N
Cheers
Simon
Jeremy Dunck
> "coming" for Django... sometime "real soon now"... how's it going?
> When might it be out?
AFAIK, Rails tries to abstract away the generated JS, and in doing so
makes code that doesn't degrade well. I hope Django does better than
that.
> 4. Rails has built-in unit and functional testing support. I don't
> know, but I'd venture a guess that few Rails apps actually USE the
> built-in testing capabilities, but it *IS* very nice... Is there
> anything like that planned for Django?
Most of core dj has doctests, but other than creating a rake driver
script and scripts directory, I don't know enough about what Rails
does. I only made it about halfway thru the Agile Rails book...
> 5. Rails has a book or two already out there -- and already out of
> sync with the version of Rails recently released. Django's book is
> "in the pipeline" but I doubt it'll be out until 0.92 gets released.
I may be overruled, but I doubt it'll be out much sooner than 1.0...
Jeremy Dunck
> On 4/12/06, Glenn Tenney <gt-d...@think.org> wrote:
> > 3. Rails supports and integrates well with Ajax. I know that this is
> > "coming" for Django... sometime "real soon now"... how's it going?
> > When might it be out?
>
> AFAIK, Rails tries to abstract away the generated JS, and in doing so
> makes code that doesn't degrade well. I hope Django does better than
> that.
Sorry for the late and redundant response...
tonemcd
particularly badly (but the author is looking more at the rapid
applications development model, where multiple XML configs and
compiling certainly doesn't help matters)
I was surprised at how well Zope (Plone actually) comes out of it. I
guess he was using Archetypes to do the heavy lifting - I've found
plone to have a *very* steep learning curve.
Django comes out well, with the caveat that Simon mentions re: i18N.
Recommended - it's 37" long though and 300+ megabytes...
Cheers,
Tone
David S.
>
> 2. In Rails you need to declare your SQL code *and* tell Rails about
> your schema, but in Django it's all very nicely put into an object
> oriented description in your model. A big win, to me, for Django.
Rails has something called migrations (see
http://wiki.rubyonrails.com/rails/pages/UnderstandingMigrations).
Bill de hÓra
> I was surprised at how well Zope (Plone actually) comes out of it. I
> guess he was using Archetypes to do the heavy lifting - I've found
> plone to have a *very* steep learning curve.
I think he used ArchGenXML. Archetypes are cool (they're a slightly
higher abstraction/dsl than Rails or Django db mappings). In an
alternate universe, where there's time to do these things, I'd port
Archetypes/CMF onto Django.
cheers
Bill
gabor
> That's a really good screencast - the Java-based frameworks come out
> particularly badly (but the author is looking more at the rapid
> applications development model, where multiple XML configs and
> compiling certainly doesn't help matters)
>
> I was surprised at how well Zope (Plone actually) comes out of it.
and i have the feeling that well... at the beginning Zope/Plone might
seem perfect, but there are some shortcomings ...not really
shortcomings, but different (from django) decisions that the zope
creators made:
- zodb. they are using an object database, which is a mixed blessing.
- it's great because you can just store objects in it. there's no need
to think in model-classes (simple classes). you just work with python
objects, and they get persisted
- on the other hand, zodb is quite a blackbox. with django, your data
are in a relational database, where a table is a table is a table. there
are several tools (gui ones and also command-line ones) to access a
relational db, to back them up, to dump/restore them etc. for zodb there
aren't that many.
- the management "gui". (where he creates for example that
python-script). it looks great, and it's great to play around with. but
after some time problems start to arise:
- your scripts are now in the zodb. so, how do you version-control them?
- how will several developers work on the files?
- how will you migrate the changes from the development-instances to
the release-servers?
- the usual answer to these questions on the forums is to not store
your scripts in the zodb (you can also store them on the filesystem),
and to not to rely on the gui stuff. but then what's the point of the gui?
yes, i had to work for some time with zope, and right now i think i
enjoy much more the "thin" approach that django chose.
p.s: of course, i'm not bashing zope there. it's a different
architecture, with different goals. and django's approach suits me
better. that's all.
gabor
lin...@gmail.com
> Several friends have been pushing me to look at Rails, so I've been reading
> through "Agile Web Development with Rails".
You have good friends, they are giving you great advice. Rails is in
it's second production release, has a huge following, and a number of
books to help document it. Django is still in a major development
phase and is geared towards early adopters and framework developers at
the moment. Many developers have opted to start there new projects
with the newest unstable development branch ("Magic Removal"/.92) so
they can reduce the pain of a .91 migration. This is fine, but you
need to be prepared to change with it. I would recommend doing the
Django tutorial, but would really think long and hard about starting a
new project with it until .92 or later is released.
> Some quick thoughts... with a couple of questions thrown in...
>
> 1. Ok, there IS the Ruby vs Python thing... I'll leave that to some
> *other* place for THAT flame fest as I do NOT want that here!
They are both good tools. You could fight back and forth but why :)
> 2. In Rails you need to declare your SQL code *and* tell Rails about
> your schema, but in Django it's all very nicely put into an object
> oriented description in your model. A big win, to me, for Django.
This is nice if you are not used to dealing with SQL directly, but
really isn't that advantageous if you are already using SQL on a
regular basis. In fact, it does present some issues with an evolving
schema. However many of those issues are being addressed with new
tools like syncdb in the mysterious .92 release.
> 3. Rails supports and integrates well with Ajax. I know that this is
> "coming" for Django... sometime "real soon now"... how's it going?
> When might it be out?
Ajax is a large pill to swallow, and Django is way behind Rails at the
moment in that department.
> 4. Rails has built-in unit and functional testing support. I don't
> know, but I'd venture a guess that few Rails apps actually USE the
> built-in testing capabilities, but it *IS* very nice... Is there
> anything like that planned for Django?
>
> 5. Rails has a book or two already out there -- and already out of
> sync with the version of Rails recently released. Django's book is
> "in the pipeline" but I doubt it'll be out until 0.92 gets released.
There is only one Rails book that is in print at the moment(non pdf).
There are several others that are going to be released very soon
though. It would be impossible to publish a meaningful book about
Django until .92 or > is out. There are MAJOR changes in .92, you
should read this: http://code.djangoproject.com/wiki/RemovingTheMagic
if you haven't already.
> Any other major differences that I missed?
There are a number of differences, but you really need to test drive
both to get a better handle on them.
--Nick
James Bennett
> You have good friends, they are giving you great advice. Rails is in
> it's second production release, has a huge following, and a number of
> books to help document it. Django is still in a major development
> phase and is geared towards early adopters and framework developers at
> the moment.
Don't tell that to Scripps or to any of the other large, conservative
companies that are quietly deploying Django ;)
Seriously, though, I think this is a misconception. Rails has reached
a *public* 1.0, yes, but it was running in production environments
long before anyone outside of 37Signals knew about it. Similarly,
though Django hasn't reached a public 1.0 yet, it was running in
production environments long before anyone outside the newspaper
industry knew about it. What Django's going through right now is a
period of expansion and refinement, as people who are finally getting
a look at it come in with lots of smart ideas to make it even better.
> Many developers have opted to start there new projects
> with the newest unstable development branch ("Magic Removal"/.92) so
> they can reduce the pain of a .91 migration. This is fine, but you
> need to be prepared to change with it. I would recommend doing the
> Django tutorial, but would really think long and hard about starting a
> new project with it until .92 or later is released.
I'm not sure what we need to be "prepared to change with"; all the
major changes which will be made are and have been documented for
quite some time. Anyone starting out on magic-removal should know by
now exactly what to expect.
> This is nice if you are not used to dealing with SQL directly, but
> really isn't that advantageous if you are already using SQL on a
> regular basis. In fact, it does present some issues with an evolving
> schema. However many of those issues are being addressed with new
> tools like syncdb in the mysterious .92 release.
'manage.py syncdb' in magic-removal has nothing to do with evolving
database schemas.
> Ajax is a large pill to swallow, and Django is way behind Rails at the
> moment in that department.
That depends on your philosophy with respect to how AJAX should be used.
Glenn Tenney
> There is only one Rails book that is in print at the moment(non pdf).
> There are several others that are going to be released very soon
> though.
http://www.robsanheim.com/2006/03/23/ruby-and-ruby-on-rails-book-roundup/
is a blog showing something like 16 Ruby and Rails books out now or out "real
soon now".
Searching on Amazon for "ruby rails" gives quite a few books (I
counted NINE Ruby on Rails books) due out within about the next six
months -- who knows if they'll slip or not.
Solid reliable up-to-date accurate complete documentation (without
having to rely on reading through the code itself and/or code
examples) is critical!
To some, that means multiple books being available (not always worth
anything, but some people just want to see books available on
Amazon... period); to others, it doesn't matter if it's one book, half
a dozen books, or downloadable files... so long as it IS available.
--
Glenn