Friday, 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.* 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 welcome.

Sanjay

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

5 comments:

  1. Anonymous4:03 AM

    While Turbogears 2 will probably be based on Pylons, it will be different from Turbogears 1 - it won't be a simple 'copy files to TG2'.

    Anyone who is in the process of picking a framework should know this. Which is why Pylons is probably a safer bet since you would be able to port a Pylons project to TG2 much more easily than a TG1 project.

    ReplyDelete
  2. Timucin Kizilay4:57 PM

    I'm likely in the same situation. I'm a business application developer and I had experience on microsoft tools in the past. But I did not like the .net so I've started to try FOSS world. I've learned python and I loved it becouse of high level data types and high level of portability. Now I'm trying to choose a framework for web applications. I've tried django and develop a web site with content management but I did not like the ORM, integration django with existing databases are not easy, so I'm looking at turbogears, it seems more application oriented where django is for developing web sites.

    ReplyDelete
  3. Nice summation, Sanjay. I hope you will post some follow up notes on scalability, performance and other factors you observe in Turbogears.

    I have done some work with Zope and I am looking at all the frameworks now trying a few prototypes.

    ReplyDelete
  4. Hi,

    You may try The Brainwave Platform also. It comes as a single unit and includes a schema less database, a templating engine and an application server. All of these are pre configured and you do not need to write hundreds of APIs to connect your backend with front end. The product is patent pending and the developer preview version is available at www.brainwavelive.com, you may download from there.

    ReplyDelete
  5. Anonymous4:19 PM

    Nice summation, Sanjay!

    But could you please show me some well-known application which use Tubogears framework?

    I found there is not many application like that

    ReplyDelete