Django is Rails
Written by Ben on November 30, 2005 |
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.
What does Django Project have on Turbo Gears?
- Django has a more cohesive and streamlined feel.
- I can use Django on the Dreamhost servers with less hassle. (Installation instructions)
- Django comes with admin interface to manage data in the database.
- Django comes with a prebuilt RSS and Atom feed generation application.
- Django provides ready to go methods for handling 80% of what you need to do (I’m talking about Generic Views).
- The URL composition and decoupling allows one to make applications really RESTful.
- Much of the work only involves wiring up the URLs and the generic views to access the data. No coding.
- I’m writing less code than Turbo Gears, which is almost nothing at all.
But I have a few pet peeves about Django:
- The App’s url.py file isn’t truely decoupled from the project. You have to specify a view’s full package and name, which the project’s name is part of. But I got around that by declaring a BASE_APPS_PACKAGE settings.py string. Now, I can just copy apps around anywhere.
- I’m not sure if I like putting the URL generation logic in with the model (get_absolute_url). This can tie an app to the project. I added a BASE_URLS settings.py dictionary to map an application to its base url.
- The options on generic views don’t mesh up well. I needed to write up a custom archive_index view, so it wouldn’t return a 404 when no data is found. I wouldn’t have needed to if the original view implemented the allow_empty parameter as found on other views.
- The generic views only can take custom SQL parameters if they are predefined. I had to extend my custom archive_index view to handle extra parameters taken from a URL path.
I’m finding that I’m spending less time on the guts of glue work; I’m focusing on delivering the business solution; I can spend more time on the user interface.
Posted in Python, Technology
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.
Comment by Adrian Holovaty — November 30, 2005 @ 2:08 pm
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…
Trackback by import this. — November 30, 2005 @ 8:50 pm
[...] 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. [...]
Pingback by import this. » Blog Archive » Django vs. TurboGears — November 30, 2005 @ 8:50 pm
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.
Comment by Cliff Wells — November 30, 2005 @ 9:02 pm
[...] 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. [...]
Pingback by Badpopcorn » Django and TurboGears, Excitement — December 1, 2005 @ 11:41 am
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.
Comment by Cliff Wells — January 20, 2006 @ 10:28 am