Python Web Framework Niches
I’ve come to the belief lately that the web frameworks available in Python are increasingly fine-tuned to specific application requirements. Of course, anyone reading the 'About’ sections for these frameworks should realize this as well. I wonder how many people actually read that section as I’ve seen people latch onto web frameworks without knowing the task it was originally made for.
Without knowing the reason the framework was created, its common for many people to leap to the conclusion that its another Rails wanna-be just because its a 'full-stack’ web framework. I was playing around with a nice full-stack framework called WebObjects years ago which made it easy to setup database objects, generate CRUD, etc. Zope’s been doing the same stuff for what now seems like eons as well, yet I don’t see people declaring RoR a Zope clone (It obviously isn’t).
In light of that, I’m inclined to agree with Ian Bicking’s response about the lessons Python web people did learn from RoR.
The concept I want to focus on is that people create these new frameworks because they make their task easier than any of the other frameworks already out there. While they might pick up features from other frameworks, most of them aren’t aspiring to be “Python on Rails”. Sometimes this task is easier when other tools can be integrated to avoid code replication, as is the case in one framework I cover here.
Many people have declared the amount of Python web frameworks a “problem” that should be “solved” somehow, perhaps a Highlander fight with swords to the death (_There can be only one!_). I’d like to suggest the opposite, there’s a lot of Python programmers and I think there’s room for even more web frameworks. The variety is a strength because they make it easier to get specific web applications done.
TurboGears
The TurboGears site has a nice about page describing its purpose, though I feel it doesn’t completely explain the rationale for its creation. There’s some interesting and unique decisions made in TurboGears, like using Kid instead of Cheetah or Myghty for templating. Then there’s the inclusion of Mochikit and the TurboGears decorators for returning output as JSON for use with Mochikit.
So what kind of applications is this web framework geared for? (Please excuse the pun)
The best way to answer this is to look at the application this framework was created for, Zesty News, and the abilities of some of the tools being used. Zesty News is in a rather interesting category of web applications in that the end-users themselves will be installing it, quite likely on their home computer rather than a server. Being able to package it up and easily distribute/upgrade it becomes a key issue along with database portability and code thats database agnostic.
Two tools assist here, setuptools for distribution/packaging and SQLObject for portable database code. Zesty News deals extensively with RSS and XML, so it makes sense that the templating language chosen was actually created for dealing with web services.
These design decisions behind TurboGears should make it fairly obvious when to consider it for your next project. The cohesive toolset you get when you choose TurboGears is ideal for developing portable, easily deployable AJAX-enabled web applications that likely deal with XML frequently and need to stay database agnostic. Even if your web application doesn’t deal with XML frequently, the decisions TurboGears makes for AJAX integration will make it easy to add heavy dynamic interaction to a TG webapp.
Django
Django was created to deal with the requirements of working in the web development department of a news publisher. As such, the framework was created specifically to deal with the requirements placed upon the author. What’s rather interesting is the lack of re-use in Django when it comes to doing things that have been done before in other projects (Database mapper, form validation, etc).
The tools and parts of Django were specifically built to work as one package, and using Django makes that very obvious. One of the things most common when in a newsroom or publishing environment is dealing with CRUD. That is, there is a lot of content and ways to get content into the system and administrate the content is a high priority. As a web framework built for dealing with Content, many of the design decisions reflect the common tasks present in CMS’s (Content Management System).
To start with, you get a slick administration interface for your conntent, that’s miles beyond any of the generated CRUD type stuff in other web frameworks. This differs from the philosophy of other web frameworks that give you basic CRUD (Scaffolding in Rails-speak) in that Django’s admin interface is aimed directly at being production-ready with no modification at all.
Django also makes it fairly easy to make a Django 'application’ like a Forum or Blog, then slot it into other Django application environments. Again, this makes a lot of sense given the original requirements placed on the creator of Django. If a company has 4 websites, and wants them all to have the new Forum/Classified ability it makes a lot of sense for this task to be optimized.
So what web applications are you going to want to use Django for?
Quite a few, as it turns out dealing with Content is a very common task. If you’re writing a web application heavy on content, that needs a full featured web interface for managing the content it’d be really hard not to recommend Django. It’s easy to get started, and in almost no time you have very powerful functionality running that gives you a lot of usability.
Don’t be Everything for Everyone
Part of the reason I picked these two projects to talk about is that they’re both extracted from a working project (as Rails was). I also haven’t seen many people mention the fact that frameworks developed in such a manner are also inherently going to be optimized for the use-cases that brought them into existence.
Open-sourcing the project lets them grow to an extent, but their design is largely baked in and a useful limitation. Too much expansion past the initial design requirement will make them generic, and with that comes a lot of complexity (sometimes worth it though for the extra re-usability).
Note that the specific things Django gives you don’t help that much if you’re trying to write a Zesty News style application. The same goes in reverse as well, since building an Admin interface of your own isn’t fun and can be time consuming. While it’s possible to make web applications that do this in either framework, compensating for framework design will require extra time when you try to use one framework for everything.
If you’re using one framework for everything, maybe its time to take a look around.
I think one of the reasons for this is that few years ago, when most of the current frameworks were started, not much mature stand-alone reusable components were available (like ORM’s or templating systems). Most framework developers had to invent everything from scratch, and get the job done in time…
I think that TurboGears (or Subway) differs in the way that it is a “new generation” framework that has more general purpose than older frameworks. When writing this I start to understand that little apps cooperating with each other give me warmer feeling than one total package :).
(pardon my English, it’s late here…)
Nice entry! Yeah, it’s all about the niche.
Frameworks are kind of like guitars. You use the one that fits your style of music.
very well said
I think it’s clear that the Python world needs the software equivalent of “Car & Driver” or “Road & Track” or “Consumer Reports”...
People don’t mind having a large selection of cars to choose from when it’s time to buy. But what helps deal with the tyranny of choice is good information on what to buy and what to avoid.
I think, in general, the Python world hasn’t had good sources of information on how to choose one framework from another, so developers are forced to do their own research or ask for opinions on mailing lists. Perhaps we should start a Python web framework rag? Maybe call it “Code & Coder”? And your post could easily be the first feature article. :-)
But then I ask, how do I do if I want:
[1] Well, the author of Subway claims that it will be there soon.
[2] I believe it has.
I’d want all those features, but now I have to choose, or mixing my own. Some of the features I want is incompatible with the current thought, like with Kid, but most of them should be possible to combinate in one super framework. I don’t think you should have to choose framework dependantly on what you are writing, the fact that you are writing a web app should be enough to ghide your choice. Otherwise I’d have to keep track of, and know my way ariound in, one framework for CMS apps, one for BBS apps, one for tournament management apps etc.
Sebastian: You’re right, you have to choose or make your own. How many other people have the same requirements as you?
A generated admin loses value if the application isn’t heavy on directly editing cohesive content that is going to mainly be contained in a single database row.
RoR tackles this to an extent by only generating basic CRUD, stubs that you build on.
I’m not sure what you mean by Complete models, but if your model is tied to the view, as Django’s is, that decision right there is likely to run contrary to what a lot of other people want. Many of the things you want, are just that, things you want.
To be all things, to all people, you will absolutely end up writing quite a bit of additional code for every web application you create. This is because you’ll have to configure all those options that the web framework gave you.
Maybe what you want is a framework that comes with every possible option that anyone could want, and you’d write a massive configuration file that your framework loads which decides how its going to operate. I seriously doubt such a framework will be as appealing as the others though.
Of course, since different people will want different layouts you’ll no doubt end up with the functional equivilant of a half dozen different frameworks anyways.
This is a nice observation about the value of not trying to be all things to all people.
First, a couple of clarifications: I chose Kid not because of its links to web services. In fact, I didn’t know of Kid’s links to web services until Ryan wrote that article…
For the most part, web applications today represent information in HTML form. There’s some information that appears in XML form (RSS, for example), and some in plain text (email). I chose Kid because I think it’s the best tool for generating HTML and XML in Python. The design part of it is as close to making straight web pages as possible, and the code part of it is as close to pure Python as possible. The current version also generates plain text, but that feature can use some improvement. If your app is just generating a couple of email messages, it may be fine though.
I should also note that database portability was a non-goal for Zesty News, though it did come in handy for me. I chose SQLObject because it looked easy to use, well-written, mature and it supported the embedded database I had chosen (sqlite).
Those clarifications aside, you’re correct that different frameworks serve some niches better than others. For any given app, you likely could be successful with many different possibilities. It then becomes a matter of which one is best suited to your app and the way you want to work.
I love the way CherryPy deals with URL resolution and method parameters, whereas others may call it a “bad and ugly thing” and use separate configuration for URLs. Both methods work fine, it’s just a matter of taste.
From everything I’ve seen to date, Django and Plone are great choices for content-oriented websites (and you’re right that there’s a whole bunch of those). TurboGears, like Rails, is better for “webapps”. I do expect TurboGears to have some decent CRUD features by 1.0, but it will be more along the lines of scaffolding than content management.
Of course, many sites have a combination of “content” and “webapps” and that’s where things get interesting. Over time, the feature sets of some of these frameworks may converge a bit. And then, it becomes even more a matter of taste.
Sure, I could go create a good website in Mighty in Perl, but ewww…
Kevin: Myghty is written in Python while Mason is Perl, which was what Myghty was originally ported from.
The power of Mason is its templating language, which introduces some concepts and syntax that for the most part doesn’t rely on the underlying Programming language, much as Clearsilver runs with totally different underlying programming languages.
Mason/Myghty’s template syntax also allows for extremely large and complex sites which are easy to maintain (or at least tolerable). This is why Amazon.com and del.icio.us use Mason, amongst many others.
This is why transitioning a lot of my Mason templates to Myghty required hardly any change for the most part. Plus, all the heavy lifting code behind the templates is then Python which means no “ewwww”. :)
I would love to see Turbogears
running on the Myghty template language …
I am starting about to start a project,
which is basically a CMS with versioning, authorization via LDAP, and user based roles for a catalogue (IP Re-use system).
I already found a small one (without django, TG, Subway) here:
http://projects.dowski.com/projects/brockman
Best regards.
shunyata
I’d say that Python itself practically tries to be all things to all people, isn’t that the spirit behind “batteries included”?
I like everythng to be there if I want to, not by default, but within simple reach. So maybe not ecveryone should be forced to use the admin interface, but for those who want to(wich is probably a great deal of even TG users) it should be there.
Oops… sorry about confusing “Mighty”. I meant Mason.
I should take a read through the Mason docs at some point to see the kinds of features it has that make it particularly suited toward large sites. I do remember seeing mention of something akin to “inverse inheritance”.
And I didn’t mean to imply anything about Myghty when I said eww… the “eww” was reserved for Perl (big Perl programs in particular) :)
Just as CherryPy can be used with different template languages, one could conceivably use TurboGears with other template languages. But, then it’s not TurboGears any more, is it?
If TurboGears were to generalize to support different template languages, JavaScript libraries and persistence layers, it would cease to be TurboGears and would probably then just be known as “CherryPy” :)
Is the templating language KID such as tight coupled and integral to TG ?
My understanding was that TG’s strength is rather being a RAD framework plus admin features plus RoR feeling above the chosen components as CheeryPy, SQLObject, etc. ...
Best regards,
shunyata
Python Web Framework Niches an excellent post exploring some of the differences between Django and Turbogears in particular. Good points made, well worth reading!...