Porting from Turbogears to Django – a personal experience

October 11th, 2009 at 5:52 am


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.


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".


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.


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.


  • 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).


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.

Related posts:

  1. How Django sessions work – introduction
  2. A simple canvas-based Javascript game, with a Django back-end
  3. Django sessions – part I: Cookies
  4. Django sessions – part III: User authentication
  5. Deploying TurboGears applications on shared hosting (Bluehost)

8 Responses to “Porting from Turbogears to Django – a personal experience”

  1. Joshua JonahNo Gravatar Says:
    Django’s way is to have several applications in a single project.

    You can put apps wherever you like and there is nothing stopping you from using one huge app for it all. It’s just a design standard. In an effort to create an ecosystem of easily installable, pluggable apps, we create apps that do very little but do it well. Also your apps do not have to be in your project. They can live anywhere you like. On my projects for example, have a folder of pluggable apps, and a folder for more integrated apps.

  2. Chris McDonoughNo Gravatar Says:

    I don’t have a dog in this particular fight (I use neither framework) but it’s interesting that both sides of the aisle use the same arguments. For example, the TG guys say that having object dispatch makes it easier than (or at least as easy as) pattern matching to know what all your URLs are. Proponents of XML-based templating systems say its *because* of designers that they ended up ditching non-XML-based templating systems (because they can roundtrip the templates through tools). I think it’s probably just preference rather than any purely rational decision, eh?

  3. salmonNo Gravatar Says:

    In TG2 instalation is much easier(easy_install) and takes few minutes, admin panel is also available.

  4. lorgNo Gravatar Says:

    I’m in a similar situation. My website ( http://plnnr.com ) is based on TG (1.0.8) and I’m not sure whether or not to upgrade.
    It’s important to note that TG 1.0.8 won’t run on Py2.6 without a fight, and so I’m still using 2.5.x for it.
    I’m still not decided regarding where to move in the future – TG2 or django.
    Like you, I really like TG’s approach to modules. The biggest tripping point for me in the move will probably be the ORM. AFAICT, moving from Kid to Genshi should be very natural, TG’s cherrpy and pylons code looks very similar, so the biggest problem will be the model, which will have to be rewritten.

  5. Ludovico FischerNo Gravatar Says:

    You ended up with turbogears 1.0 probably a bit late in its lifecycle as most of its components have become unfortunately a bit outdated.
    I think that if you use a modular framework, you need to be prepared (and have time) to learn about the ecosystem at large to benefit.
    (know about WSGI, WebOb, setuptools/Distribute; or use SQLAlchemy in non-web projects…)

  6. Jorge VargasNo Gravatar Says:

    As others pointed out moving from sqlobject to sqlalchemy is the biggest challenge. The TG1 controller api is 100% compatible and genshi is all but 2 functions different and those two are at most used ones in your app. Both moves are actually improvements over django’s counterparts as djangoORM and SO are “active record” instead of “data mapper”, as for genshi it’s much faster than kid and maintained. It is not as fast as django templates but if you want that go with mako or jinja which are far superior speedwise than the previous ones.

    On the other hand, it is close to impossible to use SA with django without losing the admin and half of the framework functionality.

    Regarding the templates as mcdonc pointed out it’s a taste thing. a XML template engine means a “visual designer” is able to pick them up and do whatever he wants in say dreamweaver.

    Last but not least duplicating django on top of TG should be very simple. Get the jinja2 renderer going and use routes which IMO is better than urls.py

  7. suhailNo Gravatar Says:

    I need some suggestion, our requirement is to build a site like youtube or dailymotion, which would contain tons of videos, so which one would you suggest, should i go with turbo gears or django or some else? Please let me know.

    Thank you

  8. elibenNo Gravatar Says:


    Well, I like Django more. But I don’t think this matters much for a video website – you’ll have other challenges like embedding the videos and providing the required traffic throughput to stream them.

Leave a Reply

To post code with preserved formatting, enclose it in `backticks` (even multiple lines)