July 27, 2007

Why I chose Turbogears

Before I express why I chose Turbogears, I must confess that I am essentially a business application developer and not an expert in python or web technologies. I do not claim my choice to be the right one, and comments are most welcome.

In the beginning of 2006, I had to explore some rapid application development tools. That time I was a jack of all trades and master of none, and was thinking to consolidate myself on .NET.

But, to my surprise, I was totally knocked down by the development productivity some FOSS RAD frameworks were offering. The potential of the MVC frameworks on dynamically typed languages (Python and Ruby) affected me so much so that I did not mind leaving everything else.

So, I planned to practice one such framework, leaving .NET.

The crucial task before me then was to choose the framework to focus on. Although people say that it should depend on requirements, being a beginner, I did not have that skill and time to learn unfocused.

There were a lot of MVC frameworks, and my rough search hinted me that the leaders were RoR, Django, Turbogears, Pylons and Zope.

I tried using Zope for a couple of weeks, but it seemed too complex to me, and then I left it and switched over to RoR.

I was happy evaluating RoR, until I found out that the default ORM of RoR does not support certain things like composite primary keys, and hence it might be difficult for me to integrate to existing enterprise databases, or develop complex applications.

Then I pondered over Django. But I quickly discovered that although it seemed as the most popular framework on Python, it was having the same ORM problem as RoR.

This left me with Turbogears and Pylons. Among these two, Turbogears seemed more complete, having many readily available/integrated components like identity management and widgets [1]. I felt that if I went with Pylons, I might still have to write some top level layers or plumbing code, which Turbogears could readily provide. Also, Turbogears was much more mature and popular, having a big user group, from which I guessed that development and debugging would be faster.

So, I chose Turbogears.

Today, I feel happy to be with Turbogears. With some experience, I had further discovered the following points to support my choice:

1. It readily supports SQLAlchemy, which seems as the best of the ORMs in its class. One might argue that nothing prevents me from intergating SQLAlchemy with Django, but being a novice business application developer with tight schedule, I am afraid of such system coding.
2. It is on Python. Python is much more widely used than Ruby, and has a lot of FOSS tools and frameworks I can take benefit of.
3. It’s a collection of many best-of-the-breed components. That means, there goes a huge amount of collective effort in the background.
4. It’s forward looking in terms of technology.
5. The future version of Turbogears, 2.0, aims to be a thin layer on the top of Pylons. What I understand by this is that I would have the best of both worlds.
6. Some benchmarks say that the performance of Django is better, but performance being a solvable problem, does not bother me much.

Comments are most welcome here.

Footnotes

[1]	As of this writing, I think Pylons has identity management and widgets, although in some early stage.