Tuesday, February 28, 2006

Python Web Application Frameworks (Part 1: A Trip To Yesteryear)

Lately there has been a lot of discussion in Python circles about web application frameworks. This has been spurred on by the success of Ruby On Rails and the perceived lack of a similar all-in-one solution in the Python world. Here I am going to try to summarise the state of the art and make a few comments as a one-time developer of such a beast. Along the way you'll get definitions, perspectives, and lots of references. Plus a joke. But only one.

Python is a great language for the web. In fact it's a great language for just about anything. It's easy to read, easy to work with, and comprehensive. There is a library for any task you might need, usually far too many libraries in fact.

And that is the problem when it comes to Web Application Frameworks (WAFs). It's not that Python doesn't have them, it's that Python has too many. It is so easy to build your own WAF that there is little incentive to use an existing one. So developers, one after the other, line up and create their own solution, driven by their own needs, and with their own perspective on how the web should be done.

But if anyone should come up with the perfect WAF that everyone agrees does the job, the least I can do, besides offer congratulations, is to provide a name. I hearby christen this mythical achievement Python Off The Rails. 1

Back when I first looked at this domain (in the last millenium) there were a few dominant players, none of which suited me. Others arose over time but they still didn't seem to be built with some of the principles I had in mind.

Of those initial candidates Zope was the most monolithic, an almost impregnable fortress of code. Modules had to be written explicitly with Zope in mind. There was an alien world of technology and terminology to navigate. Just listen to the name: Zope. You'd have to be a character named Zorg to take to that. This was certainly the opposite of what I was looking for. I wanted a simple solution that played nicely with other modules and expected you had a body with but a single head.

I also discarded Twisted, Webware, SkunkWeb, and the like. They were either too vast, complex, or low-level. They were multi-headed tentacled beasts that bathed in Freon and spat out, well, they spat out HTML I suppose. But still, Freon!

A good amount of my dislike for some systems came from their templating language. Templates allow regular HTML to be extended with additional tags or commands to facilitate generating dynamic pages. (There, that's one of those definitions I promised.) But many of these system encourage the use of Python code in HTML, following the model of Microsoft's own ASP.

I thought then that this was the worst possible idea for web development. (For the record, my opinion has not changed.) Mixing functionality with interface is a recipe for disaster. Designers should not have to care about program code and vice versa. These sorts of templating languages seemed to be written by people who expected to do all the jobs themselves and who never thought about how their tool might integrate with an entire development team.

That ruled out template systems like Spyce and a lot more besides. (I don't mean to pick on this product specifically. But since it has a catchy name it came into my head first.)

Later a second wave of sophisticated applications washed up on shore. (I suppose this had better be an alien shore 2 in order to keep my metaphors unmixed.) For example, there was CherryPy, which required that your app be compiled into a standalone HTTP server, an idea that broke all sorts of standard expectations about how Python code should behave 3. That irked me, but on a more practical level that particular architecture made it impossible to run a site at standard web hosting firms that don't allow full server access.

It seemed that developers were being too clever for their own good. Since I am rarely clever enough for my own good, I did what any decent Python coder would do and wrote my own solution. By 2002 I had released a program called Wasp4, which included session support, cookies, form handling, remote debugging, exception handling, templates, and a bunch of other goodies. It was written to work as a simple CGI process on standard web servers. Later I extended it to include its own web server, work with Twisted, etc., but these versions I did not release. In fact, I'm not even going to give you a link to it, because it is so far behind the times it looks positively ancient.

That's what happens in four years.

One intriguing aspect of Wasp was that it could be used as a static templating system: feed it template files and it would spit out the results as normal HTML that could be used anywhere. It did not need a web server at all. This facility proved most handy.

However, although it is small and concept-free compared to most WAFs, it was monolithic in the sense that the core components could not be readily used apart from one another. It was beginning to look a lot like a framework indeed and frameworks suck as many have noted. Again, this was less an issue in the current, unreleased version. (But then again I could claim an unreleased version cured hunger, helped single dads and consequently removed the need for people like Bob Geldof 5 to even exist. And how would you know. It's unreleased.)

A library allows each piece to be used if and as the developer wishes. A framework demands that the developer take an all-or-nothing approach. Frameworks are good for end-users, those building a website with little desire to programme. But they are bad for developers, who need to tweak and mix'n'match to fit custom circumstances.

So what are these "core components" that WAFs contain? It turns out that there are an awful lot of them. And that's where I'll start my discussion next time. Because I appear to have run out of space for footnotes.




1 And would claim copyright on the name, except that I know you can't copyright a name. Sheesh!

2 Despite the fact that I am or was a Canadian, this is not a reference to Rush, prog rock group and science-fiction fans.

3 Some time ago, that architectural restriction was lifted, and you can now use CherryPy with mod_python, IIS/ASP, FastCGI, or SCGI. Just so you know I'm paying attention.

4 It was originally called Goat. Don't ask. Because I don't remember. But certainly Wasp sounds much cooler.

5 For the record (aha! a pun!) I am a big Boomtown Rats fan, even if the recent remastered CDs squashed the life out of the music and contained some odd editing errors.

RELATED POSTS

2 comments:

Anonymous said...

If you'd named it Goat, I would have taken a bigger interest in it at the time! ;) Looking forward to the rest of your series.

BTW, you're missing out on some sweet -17°C weather here. Feels like spring already!

-- psj

Anonymous said...

Why feel like embarassed about your former Wasp site? :) I accidently find it on the web (oh yes, the URL is: http://www.execulink.com/~robin1/wasp/readme.html) and download it just for testing. I was looking exactly the same templateing thing quite some time...i think i found it :)

mixa

Post a comment