Thursday, January 18th, 2007
Event-Driven Web Application Design
Christian Heilmann is talking about Event-Driven Web Application Design on the YUI blog:
The crux of the matter is that we don’t really yet understand how to build a real web application. We take tried and true methodologies that cover other development scenarios and try to shoe-horn them into something that helps us to achieve what we want on-time and within budget (and when was the last time that happened?).
The other problem is that we approach web application design with browser limitations in mind and plan only for what browsers can do rather than what the application should offer the user.
When it boils down to it, the main differentiator of a web application and a web site is that an app has much more interaction and is process-focused rather than content-driven. Users come in to achieve a goal: They provide data to the application, they use the application to enhance that data, and then they expect data to come out. They interact with components of the application and expect them to do something that brings them closer to their goal. It is of utmost importance that we plan for how users interact with the product and react accordingly.
When trying to accomplish this in the browser, there is one core technique at our disposal: Event handling.
He details the event-based scenario when he details planning for an Event-Driven Application, and taking events past the DOM. Do you agree?
This was the topic of my Ajax Experience talk, so I’d have to say I agree. I’ve made the slides available as well.
Wholeheartedly agreed. In the ideal case, a developer should be able to attach hundreds of handlers to individual objects for separate events (eg. mousedown, click and so on.) My experience has been that in reality, browsers really choke with dynamic assignment and removal of large numbers of event handlers, so the delegation model (ie. a top-level listener which routes events as necessary to targets of those events) works excellently.
we talked about something similar at JavaOne last year about taking Dojo or YUI widgets on the client and pairing them with Server-Side components such that events, with a proper ID scheme could be routed back up and executed on the server, leaving a 1:1 relationship between what would be service end points and client-side widgets. The benefit here is that the end developer just says they want a ‘datePicker’ component and the Server-Side framework will mediate the events and end points for you– leaving you with a single widget declaration, not a single widget declaration, then coding/publishing N endpoints to supplement the one widget.
Are you getting paid for your awesome “Do you agree?” addition to his article?
this place rocks lol
Second abc’s comment. Dion, part of why I come here is for critical commentary! Thanks :)
Sounds like we’re moving towards reimplementing X-windows cross platform. :)
I am amazed that every time there is a post about “you guys are not real” the poster doesn’t add a real name. :)
I think this is good aproach (i’m using YUI and CustomEvent) and maybe a way to create flexible apps. I agree with Chris that we still don’t realy know how to build web apps. We need solid guidelines. Event-Driven web app desing can be one of them.
I agree with doing event-driven design… This is exactly why I implemented topics for publish / subscribe programming in Dojo. It was pretty trivial thanks to the great AOP stuff in Dojo, but I’ve got to stake my claim to something ;)
Jacob, while you talk about it, others have been doing it for a long time.
Google “Echo2″
Just a note, our Helmi Open Source RIA Framework has a fully implemented event driven application programming model for AJAX / Rich Internet Applications, including passing the events to server and very efficient AJAX communications components. Excactly a kind of platform as described to be ideal in the article. So, download our User Interface Framework and start developing event driven web applications today. :-) http://public.helmitechnologies.com