Summary
This is an interim response to the discussion that followed my previous web frameworks blog. I need to do much more research, but I have some quick thoughts.

Let me thank everybody for participating in the web frameworks discussion. I haven't been able to digest all the comments yet, and I've yet to download a single one of the many recommendations (except for web.py, because it was only one file). But I've skimmed a lot of the discussion, and tried to follow a few tutorials (many of which are unfinished, leaving me with an unsatisfied cliffhanger feeling).

So, while I educate myself more (and take care of other duties), here are some thoughts that are bubbling through my head at this point.

Maybe the current crop of Python web frameworks (as well as Rails BTW) have it all wrong. Maybe the WSGI folks are the only ones who are "getting" it.

ISTM that, contrary to what Rails and its many imitators seem to think, a framework shouldn't be an all-or-nothing proposition. For example, in the case of my Google starter project, I need to roll my own solutions for authentication and persistence (since these must hook into internal Google infrastructure), but I really need a better templating approach than %(name)s. So I should be able to use Django's templates, or Cheetah. I really want to look into Cheetah -- the example I saw on web.py looks "right". (web.py itself OTOH gets an "F", for undocumented code with too much magic behavior. upvars(), bah.)

Maybe we need more standardization efforts like WSGI, that let you plug in different animals, or roll your own, for various pieces of useful web functionality: for example URL dispatch, templates, persistence, authentication, sessions, forms, style sheets, i18n, and client-side scripting (AJAX or not).

Not that I'm particular keen on WSGI -- it reminds me of a trip to East Berlin in the mid '80s. But its point is to provide a minimal interface between the web server and the typical web application, and to support most existing solutions on both side of the fence. The former is the real point, of course, but the latter is extremely important for standardization efforts. (Remember ISO networking? No? See, that proves my point. :-)

Here's another point. Or perhaps a set of chaotically related points. Some frameworks emphasize that the effort of getting started is low. But this is really only so to the extent that you're trying to do something very similar to something that's been done a 1000 times before, so that all the defaults in the framework and the setup utilities are all doing exactly what's needed. This (and very fast typing) is what makes the first Rails movie possible.

But what if you need to into an existing authentication framework? What if you need to hook into an existing database schema that maps to in-memory objects in a different way than the framework's ORM tool? Or if your persistence approach is not based on a relational database at all? What if you want to write an AJAX application like Google Maps or Gmail? Etc. -- for every framework component there's an alternative that you might want or need to use instead of the default.

I remember the time, before the web, when GUI apps were new. We were all learning about event handling, scrolling regions, screen refresh, window placement, text editing, and so on. Soon enough, frameworks emerged that took care of the repetitive stuff, leaving the application developer free to develop an application. But IMO it didn't work all that well. Perhaps it worked well for some apps, that really were very similar to the "ur-application" that the framework designers had in mind. But usually the framework didn't do exactly what you wanted, and then you had to tell it to do things differently. Perhaps you didn't want a horizontal scroll bar on that window. Perhaps you didn't want to automatically change the cursor to an hourglass for certain operations. Or perhaps you didn't want windows at all! Let the whole screen be a canvas. Etc., etc.

For many applications, the choice was between either using a GUI framework and writing lots of overrides to fight (some would say "extend") the framework; or using a more simplistic, lower-level GUI toolkit and writing more low-level code but being more in control. Which approach was the quicklest way to success wasn't always clear, but here's my take: personally, I'd rather use a bottom-up approach, where I can start writing simple code that forms the core of my app, without relying on framework services. Then as I find the need for templates, authentication, sessions, persistence and so on, libraries should be available to do the heavy lifting.

Perhaps frameworks could fit the role of "profiles" -- a set of libraries that is necessary and sufficient for a particular type of application. For example, there could be a profile suitable for building social networking sites, one for setting up on-line stores, one for enterprise intranet applications, one for community websites and so on. These would have different levels of sophistication, and different number of components, but there would be a considerable amount of overlap (e.g. the on-line store profile and the enterprise intranet profile may both provide session management out of the box).

I'm halfway through Joel Spolski's book, User Interface Design for Programmers. It's a great, light read (and a great companion to Steve Krug's Don't Make Me Think). Joel notices a pendumum swing in UI design paradigms: from classic power-apps that give you an empty window and a loaded menu bar, to auto-content-creation wizards focused on specific likely activities that leave the expert frustrated, and back again to a more reasonable mid point. Perhaps WSGI represents the "blank slate" approach; Rails/Django represent the wizard approach; I'm still looking for the ideal mix-and-match solution.

From this perspective, Zope and Twisted are off the scale: they support the mix-and-match approach, offering several alternative solutions for many of the important issues (templating, persistence, authentication, etc.). But they only work if you drink lavish quantities of their particular flavor of kool-aid, and that's not good enough for me. I don't want to depend on any particular flavor of interfaces, adaptation, serialization, discovery, etc. I'm looking for solutions that depend only on the Python standard library, and use accepted Python idioms and patterns. Any takers?

Talk Back!

Have an opinion? Readers have already posted 33 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Guido van van Rossum adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Guido van Rossum is the creator of Python, one of the major programming languages on and off the web. The Python community refers to him as the BDFL (Benevolent Dictator For Life), a title straight from a Monty Python skit. He moved from the Netherlands to the USA in 1995, where he met his wife. Until July 2003 they lived in the northern Virginia suburbs of Washington, DC with their son Orlijn, who was born in 2001. They then moved to Silicon Valley where Guido now works for Google (spending 50% of his time on Python!).