Python Web Frameworks
It's always been a bit of a surprise to me that Python hasn't become more popular than it is for web development. In the early days of the web, Python was positioned as a natural competitor to Perl, which was the leading choice for dynamic web apps. However, while Python gained a lot of attention as an general alternative scripting language to Perl, it didn't become as popular as Perl had been for web development. Instead, Java became the language of choice for large scale web development, with Java Servlets, Java Server Pages, and Enterprise Java Beans growing Java web development into a mini industry, complete with developer certifications and widespread adoption among large corporations.
If you asked a Python developer over the years why Python wasnt more popular for web development, at least part of their response would very likely have mentioned the corporate popularity of Java and it's web development platform. Indeed, the prevailing corporate preference for Java certainly was a major reason why Python didn't become more popular for large scale web development. At the same time, PHP gained widespread popularity for low end web apps.
The most popular Python web framework was (and maybe still is) Zope, and in fact Zope had it's own surge of success. In late 2000, Digital Creations, the company which originally developed Zope, closed a $12 million round of series C funding. Around the same time, Digital Creations changed its name to Zope Corporation, and hired Python creator Guido van Rossum and his PythonLabs team of 4 core developers.
Guido spent almost 3 years working for Zope Corporation, so I was a bit surprised earlier this year when he posted a blog entry titled "Please Teach me Web Frameworks for Python!". Reading his post, the first question that came to mind of course, was "why not Zope?" I think I have some idea about that - Zope is fairly monolithic, and has some surprising idiosyncracies. Reading the responses he got, though, brought up more questions for me - I was really surprised at how many different recommendations he got - there was far from consensus.
So why is there no consensus choice for Python web development? At one time Zope seemed be headed in that direction, but it was found by many developers to have some fatal flaws. It is my contention that the presence of Zope held back the development of alternative Python web frameworks. Not directly of course, but indirectly by driving programmers to consider other languages for web development.
In fact much of the buzz in the web development world over the past year or so has been about Ruby on Rails, positioned as a lighter weight alternative to Java based frameworks, yet more maintainable and structured than PHP. When I first learned about Ruby on Rails, I thought it sounded like the kind of framework I had been looking for in Python. The popularity of Ruby on Rails, with many programmers learning the Ruby language just to use it, shows that the corporate preference for Java wasn't the only thing holding back Python. Luckily, the success of Ruby on Rails seems to have led to some increased activity in the area of Python web development. Two contenders that stand out for me are TurboGears and Django.
Django is in fact the technology I ended up choosing to power this site. So far I'm very pleased with the quality of the Django design and documentation. It hasn't quite reached 1.0 status, so there are still some rough edges being worked out, but the basics all seem to be in place and work well. It is also easy to use, especially if you know even a little Python.
For me, Django does something which is a challenge for all frameworks - it simplifies common tasks in its problem domain, but at the same time it retains enough flexibility to let you step outside the framework as needed. One friend of mine is fond of saying he hates all web frameworks, and I can sympathize with the sentiment, but I think a well balanced framework is definitely better than none at all. My own definition of a web framework includes this list of features:
- Persistant processes
- Cookies
- Http requests
- Http responses
- User sessions
- Templating
- Url dispatch
- Data persistence (e.g. Object Relational Mapping)
These features are present one way or another in all of the web frameworks I've mentioned in this article, and I think Django does a good job with it's implementation.
When I say persistant processes, I mean the ability to service multiple requests without spawning a new process on the web server. This is almost taken for granted now, but in the old days it was actually a big deal that Java Servlets had this feature, as opposed to traditional CGI apps which spawed a separate process each time. The most obvious way to achieve this in Python is to use mod_python with Apache. The next 3 features in my list are also provided by mod_python. In fact, one sensible choice Django made was to piggyback on top of mod_python.
Continuing down the list, we start seeing where Django adds its value - user sessions are a very nice convenience, and a templating language makes the frontend part of web development much simpler. There are a few approaches to templating, including embedding a full powered language into HTML, using XSLT as a conversion layer, or using a custom template language with (purposely) limited power. The first approach has lost favor over the last few years because it doesn't follow the Model View Controller pattern, potentially leading to maintainance problems. The XSLT approach has a lot of theoretical appeal, but the custom template language approach seems to have been preferred by web designers, who often end up being the ones writing the template code. Django follows the custom template approach, and their template language actually garnered some praise from Guido himself.
Django's Url dispatch mechanism is actually one area where I had to experiment a bit to get things working correctly. However, I found the end result very nice, and the mechanism is extremely flexible. Most importantly, it results in "beautiful" urls. Django encourages you to "desgn" your urls, and I agree with their philosophy that the end result is work the (slight) extra effort.
The last feature in my list - object relational mapping - is one which generates the most controversy when discussing web frameworks. For some reason I've never quite understood, there seems to be an inherent fear of SQL in the web development community, and over the years there have been many efforts to hide the SQL completely (or in the case of Zope, encourage the use of a custom object database instead of a relational database). Personally I'm wary of any form of object relational mapping which works automatically. What I do want is a nice abstraction layer (sometimes called the data access object pattern), so that the code working with objects doesn't know that the objects are actually stored in a relational database.
If Ruby on Rails can be taken as evidence, the trend is towards tighter integration with relational databases, and towards automatic generation of object relational mappings. Django does follow this trend in general, but it also makes it possible to cleanly do the mapping manually as well. I was relieved to find that Django supported such manual mapping, and it's a topic I plan on writing about here in the future.
Posted by Steve Hutton on Sun, 25 Jun 2006 22:50:00 +1700 [Permalink] [More on Django]Previous: SOCI Article in this Month's Dr. Dobb's
Next: Programming with Exceptions
