Django, Turbogears, Rails and the +- feature curve
I watched quite a few google tech talks over the past week. I started out with Jacob Kaplan-Moss on Django. That talk got me to watch Snakes and Rubies (full 3.5 hours). It has Adrian Holovaty, one of the creators of the Django framework for Python, and David Heinemeier Hansson, the creator of Ruby on Rails framework. Great set of talks and I'm sorry I hadn't looked at it before. That got me interested Guido on Python 3000.
David (Rails) comes across like Mark Fleury of JBoss with an entertaining arrogance you don't really see in tech talks. If Rails doesn't do something (i18n) it's not that important or a trivial implementation detail. He says reuse is vastly overrated for instance. He admits he didn't reuse any existing Ruby components in Rails. He said that there's an inherent hypocrisy among framework designers as they want to have total control over every line of code in their framework but expect others to use the framework as given. Their initial marketing came to down to picking a big target (Java) and make provocative statements to get you known in that community. It the strategy worked for Fleury with people on projects where WebLogic/WebSphere were the safe choices.
I like it that David shakes things up and this is good for dynamic languages especially Ruby. Pylons is "marketed" as response to Rails marketing - you know the context straight away. We may finally be getting over C language legacy. The designers of the newer frameworks take PHP as their reference point. I like Python and it seems to me like Ruby+-. Java was known as C+- as the philosophy is that in that for every feature they added they took away two. C++ just kept adding features and if you add a feature someone is going to want to use it. You get a hit when you try to maintain code using strange combinations of the various features. I think Java 1.0 got a lot right on the plus/minus feature curve. David was fond of Ruby's "Micro-Languages" as I guess it's more control for the framework designer but a reader can't sit down and understand it straight away. Rails is big on beauty but beauty is always in the eye of the beholder.
Turbogears (or equally Pylons) is (mega-)framework that reuses existing components so kudos for that. The problem is in coordinating with external projects. One criticism of Turbogears is that while the core is well written it is let down by its components. Turbogears started out with 4 components and already two have effectively been deprecated - the problem is moving to the new components that are kinda supported but not quite yet.
There was an interesting post from Paul Johnston on the turbogears list. He argued that Django was excellent but
the problem I found with Django was that if you wanted to do something that doesn't quite fit its approach, you're back to doing things the long-hand wayand concludes that
frameworks are becoming more like distributions every day.The problem of integrating many components was recently highlighted in a thread on the Future of MochiKit by Bob Ippolito:
Because it took on all of this new functionality, none of the developers know and use all of the library anymore (e.g. I don't currently use anything in DragAndDrop, Sortable, or Visual) so it's harder to know what the overall status of everything is and it makes it harder for me to confidently do a release.
The thing I like about Django is that it has a specific purpose - it's a web framework for perfectionists with deadlines. The perfectionists are the developers who write Django and have control of the entire framework. It's a bit like Rails in that regard. After watching the videos the Django perfectionists are bright, thoughtful and pragmatic but never dismissively opinionated. The benefit for the framework user is that everyone is using the same thing and the documentation is excellent. All the deployment issues in supported environments are solved problems. I like that it has been validated against the difficult time-boxed online-news problem domain so it should be usable in most situations.
Django is really good at web development but you can run into problems with specific unsupported deployment configurations. For instance a patch for Oracle support won't be integrated until a maintainer is found. Turbogears will work as long as some ORM component has official Oracle support. Django has a very strong community so you know that these issues will be addressed.
There is a good background talk at Pycon 2007 on Python Web Development with Django. It has some context for Python and web frameworks which is useful.
I like Django and it's great that there is a Python web framework for perfectionists with deadlines. But if I wanted a mega-framework to get Jython working with a selection of Java components (e.g. Spring, Servlet, Hibernate and Velocity) it's nice to think I could use Turbogears or Pylons as a starting point. Mega-frameworks let you dabble with framework design in your own right - integrating a pallet of components to get just the right balance for your problem domain. Before watching the three talks above I would have naturally veered to Turbogears or Pylons but today I think I get why we need to support Django. Choice is a great thing and it's fascinating to watch all these things develop. It's all about where you want be on the less/more +- feature curve.