On the Next Big Web Application Framework
by Ian Langworth
- 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
- 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.
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.
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.
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.
|@Jacob, you might be right... but if you're right, does that mean that pure HTTP is inappropriate as a protocol for applications?|