[python-advocacy] The python way to write web applications

Paul Boddie paul at boddie.org.uk
Sat Oct 13 19:44:18 CEST 2007


On Friday 12 October 2007 06:12:08 Tennessee Leeuwenburg wrote:
> I've got a problem. Please, hear me out in case I've got it jumbled. Then
> feel free to criticize my understanding of things -- I declare Crocker's
> rules.
>
> There seems to be no Pythonic way to write web applications.

And the nominations for sweeping statement of the year go to... ;-)

> There are python web application frameworks, but these stacks still require
> a lot of javascript expertise. It doesn't look as though I can write a
> cross-platform RIA with Python, authored from a linux development
> environment.

I guess what you mean is that the Python Web application frameworks which 
support "AJAX" or "Web 2.0" functionality require the developer to learn some 
JavaScript library. That may be true for some of them, but certainly not all, 
as Jurgen points out. Indeed, if I could only get round to enhancing my own 
Web application framework slightly, it'd support something like KSS instead 
of the developer having to write the occasional event handler in JavaScript; 
then they wouldn't even need to know how to write a simple function call in 
JavaScript.

Anyway, I'm not really a believer in filling Web pages with JavaScript for 
fancy desktop application-like behaviour which either doesn't work properly 
in 80% of browsers (and it's a different 80% every time) or which cause the 
whole application not to work at all since the user turned JavaScript off: a 
legitimate choice given the continual stream of cross-site scripting exploits 
or implementation issues. See Google Picasa for an AJAX-laden example of an 
application which doesn't seem to work satisfactorily in any browser.

> I can write flex applications, but apollo isn't ready for linux yet. I can
> write Moonlight applications, but the authoring process is poorly
> documented, requires compilation of mozilla from source (!) and isn't
> up-to-date with respect to Silverlight. If I'm happy to constrain my widget
> set, I can use some javascript toolkits to hide away the javascript to some
> extent, but certainly for my purposes, and probably for all purposes, I
> just know I'll be up to my elboys in javascript in no time.

You could possibly write XUL-based applications together with PyXPCOM, but the 
effort involved in building a capable browser still seems to be significant. 
Still, it's arguably better than mixing in Mono as well. One day I'll return 
to the task of making KHTML/WebKit work with Python - another thing which has 
proven to be awkward over time.

> I could try swigging mozilla and interacting with the browser directly, but
> this is a jungle of old documentation and is clearly not a well-supported
> process.

Yes, most wrappers around Mozilla or Gecko don't touch the internal stuff like 
the DOM.

> The premier web toolkits like GWT and YUT appear to be totally
> Java-oriented.

And aren't they still fairly proprietary?

> There just doesn't seem to be a Python solution to a modern web
> application. The best I can now imagine is a decoupled system with Python
> on the backend. Frankly, in this situation I don't see the point. The whole
> point of a web application is to present a cross-platform user interface
> using a deployment model which allows good control over the environment. It
> is, essentially, a UI decision. To give up Python on the UI seems to be
> giving up the very core of what it means to write a web app.
>
> Please, somebody, tell me I'm wrong!

You're wrong! ;-)

My view, already regarded as extreme by the "users must have JavaScript 
switched on to use this application" [1] is that the AJAX stuff should 
provide extra interactivity over and above the rest of the application. Now 
you could always go and write a load of JavaScript code to provide this extra 
level of comfort (or special effects), but then you've got to make sure that 
it remains consistent with the rest of the application, that it doesn't 
provide the only way for users to achieve certain things, and so on. You 
could write this stuff in Python and have it translated to JavaScript, too, 
but in the end you have a maintenance problem if the additional stuff has 
significant amounts of custom logic.

In the end, we return to the observation that the logic should be in one place 
and that we make the "view" part of the architecture capable enough to 
provide a nice interface without the temptation to write our application in 
the Web page templates, PHP-style. In attempting to reinvent traditional GUI 
programming this observation has obviously been forgotten.

Paul

P.S. Isn't this really a Web-SIG discussion?

[1] http://blog.ianbicking.org/on-form-libraries-comment-17.html



More information about the Advocacy mailing list