Searching for the ultimate web application framework (longish)

[Paul Boddie]

Tim Ottinger <tottinge at indy.rr.com> wrote in message news:<3E5C0283.6090308 at indy.rr.com>...
> 
> I'm not sure what the need is for a framework that goes
> beyond what editors, CGI, XML, XSLT, and apache can do.
> When things go beyond LAMP, I begin to wonder if they're
> not being done in the right environment.

Interestingly, one of the major criticisms in this thread (with a
twist of corporate self-promotion, although that's not exactly
unjustified) is that the "round trip" approach employed by browsers,
due to the architecture of various Web technologies, is inefficient
and doesn't fit in well with existing graphical user interface
development paradigms. My own opinions on this are:

  * Sending whole forms to and from the browser may be inefficient,
    but decent browsers can always reduce the confusion that the
    user may experience because of this. Even whole page refreshes
    can be optimised by the browser - IE4 was doing this years ago
    (on Solaris, even, when it wasn't crashing the X server), and
    most browsers don't behave like Netscape 4 any more.

  * It might be inefficient to send lots of data, but it has taken
    a long time for a non-proprietary, efficient Web forms standard
    to even be agreed upon, let alone deployed - how many "real
    world" browsers support XForms anyway?

  * In many situations, the "lots of data" argument is rendered
    irrelevant by the bandwidth available. Arguably, the kinds of
    applications which have lots of data on screen are also the
    kinds of applications which run on intranets. Still, decent Web
    frameworks should allow you to offer "broken up" sequences of
    forms as an alternative to one "megaform" without having to
    extensively redesign and reimplement large parts of your
    application.

  * Trying to be clever about what gets sent between client and
    server, and then trying to implement this in a generic way, can
    become a difficult thing to accomplish well. I've seen these
    kinds of frameworks in action (a long time ago, too), and unless
    you introduce a good separation between presentation and logic,
    it gets extremely messy and unsatisfactory. One might argue that
    lots of "database forms" applications seem to manage things
    efficiently, but I'd argue that such applications tend to become
    pretty specialised around the data being represented.

  * Many people have pushed various "rich clients for the Web"
    before now - six years ago, every industry pundit with an
    opinion was claiming that Java would be ubiquitous and that
    almost every e-commerce site would implement their forms as Java
    applets. Given that the "smarter money" in e-commerce (such as
    Amazon, for example) have seemingly never let Java anywhere near
    their Joe Public user interface (at least as a means of data
    entry), I would suggest that despite the supposed inelegance of
    the Web forms technology of the day, "real world" users have a
    different set of priorities - sending long forms can sometimes
    be expected to take some time, whereas users get impatient with
    Java applet download and initialisation even today.

> Someone could look at the bottom of this page
> http://www.boddie.org.uk/python/web_frameworks.html
> 
> Maybe there's some good stuff there.

The good stuff can now be found at:

  http://www.python.org/cgi-bin/moinmoin/WebProgramming

Paul