Eli Bendersky's website Introduction
About a year ago, I taught myself Turbogears (version 1.0.7 at the time) in order to write a small personal web-application for my own use. Although I have very little web development experience, Turbogears was easy to use, and its power was apparent.
Recently I've decided to make some improvements to my application. However, in the meantime TG moved on to version 2.0, and because of the many changes it came with, I had two options. Either stick to the old TG version or learn what it takes to use 2.0. Since this is mostly a learning experience, it was a shame to just use an old version. On the other hand, if I need to learn a new approach (for 2.0) anyway, I could learn another framework, while I'm at it.
This is how I got to Django. I made up my mind to rewrite the application from scratch, and to learn the other large Python framework in the process. This post summarizes some of my (highly subjective!) thoughts about it, and how I see the differences between TG and Django.
Components
A big difference between TG and Django is in their basic architecture and philosophy. Django is a monolithic framework with an ORM of their own, a templating engine of their own, and so on. TG ties together several independent packages to do everything.
When I first started checking out the frameworks last year, this is what decided in favor of TG for me. I figured that tying together several well-known and tested packages is a better approach. If I'll have to do something other than a web app in the future, I'll be able to just reuse this knowledge and, say, use SQLObject (TG's ORM in version 1.0.7) for other things. The same with the templating engine and so on. Django just looked like everything depends on everything else.
On the other hand, consider this. TG 1.0.7 had SQLObject for the ORM, Kid for the templating and Cherrypy for the controller (HTTP event handler). TG 2, on the other hand, has SQLAlchemy for the ORM, Genshi for the templating and Pylons for the controller. Now, this isn't exactly persistent, and investing in becoming an expert in SQLObject wouldn't really pay off, would it?
Django, being monolithic, has stayed much more consistent during its evolution. Of course if you really want, you can use other components with Django - so if you really dig SQLAlchemy you can replace Django's ORM with it. It takes work, but it's possible. You can also use Django's components outside of Django, if you really want to. It's less natural than with TG though.
That said, I have a feeling that Django can be a bit too inflexible when you need to really customize it. It gives you less freedom than TG to against its "way".
Documentation
TG has nice documentation, but Django is simply in a league of its own - not only against TG, but against most Python libraries and frameworks. Besides the excellent online docs, you also have a complete book for free online. Since it's the most popular Python web framework around, there's also a lot of unofficial documentation and tutorials floating around the web.
To use TG you should really go through the docs of its components, so you have to look in many places. For Django, it's all in a single place, logically linked together.
Installation
Django took much less time to deploy on my Bluehost account. The installation took a couple of minutes and was very well documented. TG was more trouble - it took a couple of hours to make everything work. I suspect that this is, again, because TG consists of several components that should all be configured to work just right together.
Miscellanea
- I really like Django's urls.py approach: your URLs are in a separate file from your controller functions. This has several benefits: (1) Things are more decoupled, which is always good - it helps reusability and maintainability. (2) The urls.py is a good "table of contents" for your website - it makes it simpler to find out quickly what is where (I'm talking about the developer, of course, not the user).
- Django has a nice automatic admin, which I don't recall in TG.
- I like Django's template language much more than Kid. It has all the required features, is easily extensible through Python code and most importantly, isn't XML based like Kid. Template languages are supposed to be aimed at designers and content editors - not programmers. Thus, using XML for them kinda beats the cause.
- Django's way is to have several applications in a single project. This isn't natural for small applications - and in TG you don't have to do it.
- Django's settings file is pure Python, which is far better than TG's INI file approach (in version 1.0.7 - maybe it's been changed already).
Conclusion
Both frameworks are very good, in my opinion. Working with Python is a pleasure (especially after you've tried to tweak your Wordpress by writing some f****** PHP code which made your eyes bleed), and the frameworks make web app development a snap.
But there's always a favorite, right? And my favorite is Django. I just liked it better - the documentation, the internal consistency, etc. I think that for me, a developer of small and simple web apps, Django is the best choice - it lets you get to where you need to go with the least effort. Maybe TG is better for the larger applications, maybe not, I can't be really sure.