The entry of TurboGears into the Mêlée that is Python web frameworks has generated quite a splash. As anyone following it will know, the whole Web Framework Wars really kicked off when Ruby on Rails was released. Rails was the development platform used for the unimpressive Basecamp, and the developers decided to release it as a framework in it’s own right.
Rails generated quite a splash, partly because of it’s use of AJAX techniques, partly because it was written in the obscure (but by all reports excellent) dynamic language Ruby, but mostly because of their superb marketing, including a 15 minute introductory video which shows how easy it is to build a simple web application.
This generated such a lot of froth that immediately a bunch of people in every coding community out there started replicating the Rails story, with varying degrees of success. These approaches are so called “full-stack”, in that they provide every piece of scaffolding necessary to build your application. This basically consists of a persistence system, an object acquisition framework, a rendering engine and some templating machinery.
And indeed, all of these projects demonstrate that using only tens of thousands of lines of library code it is remarkably easy to build a simple web application. Big deal. This should not really come as a surprise to any of us – simple applications are, well, simple.
The really interesting frameworks, to my mind, are those that deal with the hard problems. Wiring a SQL Database to a templating engine using a bunch of glue code is not rocket science.
Providing an architecture for flexible large-scale development is a very different problem, and the one that should really be concerning the framework developers out there. If you think you’ve won because someone with little prior experience can write yet-another-todo-list, then you are missing the point.
Incidentally, because of their limitations, more traditional non-dynamic languages (i.e. Java) are sort of scuppered here – although there have been attempts to provide more interesting architectural motifs such as Aspect Oriented Programming for Java the constraints of these languages make these cumbersome and often syntactically so difficult as to be offputting.
In Python, my language de jour, there are two web frameworks that in my view really make a major architectural attempt to provide a framework for large scale application development. The first is Zope, more specifically Zope 2. This provides a pure-OO database, the ZODB, and a system of object traversal called “Acquisition”, designed to provide a way of doing runtime overloading of object attributes depending on context. Zope was a brave and interesting attempt to solve a real problem in building large applications. Unfortunately, acquisition turned out to be a real train-crash in real world development – but at least they tried! It’s a far more interesting solution than any of the other Rails clones I’ve seen. Zope 3 looks to have solved this problem, using the Adaptation techniques used in Twisted, however I’ve been unable to get past the use of XML for config files, which has made me flee in horror.
The other is Twisted. The guys who wrote Twisted inhabit a world of such extreme abstraction that it makes my brain hurt just to think about it. However, for big problems, serious abstraction is a good thing. Combined with some of the products from Divmod, for example Nevow and the spiffy new Axiom, you do really get a framework that I think solves many of the major problems in building large scale applications that remain flexible. Beware though, the one thing it doesn’t do is make it easy. This is not for the faint of heart.
0 Responses to “Web Frameworks, and Why Most of them Suck”