Comments on: Django is Rails

By: Cliff Wells

Cliff Wells — Fri, 20 Jan 2006 18:28:34 +0000

Well, my opinion has changed drastically since I first read and commented on this article. I’m using Django for a fairly large commercial project and have done several small-to-medium sized projects in TurboGears. Django is still the more mature framework, but I can tell you which one is the one I look forward to doing new projects in (and it isn’t Django). Django is a great product, mature, stable, well thought out, and… yawn… I’d rather hack my way through TurboGears any day, warts and all. TurboGears is *exciting*. So I guess which one is right for you depends on where you like your tools to be: stable and boring, or cutting-edge and fun. Too bad there’s no current happy medium, but I know for myself, my productivity is directly tied to how interesting a project is, and Django just takes away the interesting stuff and leaves me with the work, whereas TurboGears practically demands you do cool things, and gives you a nice framework for doing them in.

Anyway, I think saying one beats the other is a bit silly. I think they appeal to different mindsets and that’s great. I suspect there’s less competition between projects than people like to think.

By: Badpopcorn » Django and TurboGears, Excitement

Badpopcorn » Django and TurboGears, Excitement — Thu, 01 Dec 2005 19:41:50 +0000

[...] My last post made the claim that Django hands down beats TurboGears. I know I may have sounded like a “fanboy” (I’m not), but I couldn’t contain the enthusiasm of what I saw. [...]

By: Cliff Wells

Cliff Wells — Thu, 01 Dec 2005 05:02:10 +0000

Glad to see someone else trying both frameworks and having a definite opinion. I’m also going with Django for the time being, but I suspect TurboGears will quickly catch up (and possibly surpass) Django in the near future. The rate of development for TurboGears is quite astounding (consider the relative ages of both projects). As an example, your second point about TurboGears not having an admin interface is already wrong. Catwalk provides a similar (and in some ways, more flexible) tool for TurboGears and is part of the core distribution in the next release. Also, I found installing TurboGears locally within a virtual host (versus system-wide) to be a poorly documented compared to TurboGears.

TurboGears seems quite a bit more open to outside developers (probably because it’s based on existing modules rather than being written from scratch by a closed group) and I expect this will help propel it along quite nicely. Several well-known Python developers have already joined the project.

Whatever the case, I’m glad to see some real progress in the Python web framework arena. I was *this* close to starting in on the Ruby tutorials.

By: import this. » Blog Archive » Django vs. TurboGears

import this. » Blog Archive » Django vs. TurboGears — Thu, 01 Dec 2005 04:50:55 +0000

[...] That is certainly the case when Ben pulls no punches in Django is Rails: The Django Project kicks the living crap out of Turbo Gears for python web application development. I went through the tutorials and documentation from both projects; messed around with writing up some toy applications. I have to say that I’d choose Django for my work. [...]

By: import this.

import this. — Thu, 01 Dec 2005 04:50:26 +0000

Django vs. TurboGears

It seems that it is almost impossible to talk about one web framework (be it Django, TurboGears, or Ruby on Rails) without drawing some comparisons and talking about which one is best.
That is certainly the case when Ben pulls no punches in Django is…

By: Adrian Holovaty

Adrian Holovaty — Wed, 30 Nov 2005 22:08:00 +0000

Thanks for this fine writeup!

Regarding your pet peeves:

1. That’s just default behavior. In my personal projects (and in the World Online projects, such as ljworld.com and lawrence.com), the apps live in their own package, rather than within a “project.” We invented the projects concept for quick-and-easy apps.

2. I agree about get_absolute_url — and we’re definitely up for changing it. I’m sure we’ll come up with a cleaner method soon.

3. I just added support for an allow_empty parameter for the archive_index generic view and updated the docs. Thanks for the suggestion!

4. This will be improved shortly, as well — there’s a patch for it in Django’s ticket system, but we haven’t had a chance to integrate it yet.