On the Next Big Web Application Framework

by Ian Langworth

At OSCON I attended a handful of the sessions that were sessions were related to web application development. I've compiled a list of features I'd like to see in the next web application development framework:

  • Give me continuations. Let my request handlers check whether the user has authenticated and, if they haven't, prompt the user and resume execution in the handler without losing state. If the user has requested to delete something, confirm the deletion first. I want this type of logic in the controller, not as a confirm() method in the JavaScript.

  • Let me attach listeners to server-side models and update the interface when the data structures have changed. For example, given a list of favorite movies that is stored in memory or in the database, I want a <div> to be modified automatically when a favorite is added or removed.

  • Keep the API simple. Give me little languages, DSLs, data structures or whatever the fancy name for them is. Let me focus on the logic of what I'm doing. Don't limit these little languages to only configuration files -- Let me write my HTML templates in whatever language I'm using throughout the rest of the framework.

  • Make sure testing is a breeze. Let my tests "click" on <div>s and make assertions on the contents of elements.

Fortunately, there are a few frameworks that have some of these features already.

  • Google Web Toolkit lets you write applications entirely in Java. The Java that needs to be run client-side is compiled into JavaScript. Designing interfaces in GWT is similar to the popular toolkits for desktop applications, and the testing framework seems solid.

  • Jifty, a Perl framework created by Best Practical, includes a lot of the aforementioned. Templates and tests are all written in Perl in a mini-syntax, and they're working on compiling Perl to JavaScript. It even has continuations.

Above all, I never want to have to write an <a href="..."> tag again. Giles Bowkett, in his HREF Considered Harmful talk, explained that it's the modern equivalent of GOTO. I agree.


Jacob Kaplan-Moss
2007-07-30 06:55:43
Wow, I couldn't disagree more. All of these goals seem designed to let you ignore the fact that you're writing a *web* application. That's like designing a car that lets you ignore you're driving on roads -- it just seems silly.

A good web framework should work *with* the constraints that the web imposes, not *around* them.

2007-07-30 11:13:50
Everyone pretty much agrees that manual memory management with malloc()/free() is unnecessary for most problems, which is why all new languages have automatic memory management.

So why shouldn't web frameworks automate the rather boring request/response loop, so programmers can start thinking about application flow instead?

2007-07-31 12:19:41
@Jacob, you might be right... but if you're right, does that mean that pure HTTP is inappropriate as a protocol for applications?