As a Web developer, I have a confession to make: I prefer writting desktop applications.
With desktop applications you can have a single class that represents a GUI widget through its complete lifecycle. Instead of form submissions and page requests to drive activities, desktop applications use events that are associated with the widgets that generated them. The interface does not need to be recreated with every request, but instead modifications to existing widgets can be used to report errors, create context-sensitive help, or update information in real time.
I dream of the ability to write a Web application using an event-driven widget-based program. I long for the capability to write a single line of code that displays a modal window, waits, and returns with the user’s response. Instead of using page-scope or session-scope variables, I’d love to see the flow of control return to a sleeping thread that represents the running application. In the end, it would be amazing to have a simple open standard GUI “library” against which you compile a desktop-like application, and *poof*, it works on the Web. With the maturity of W3C’s Document Object Model (DOM) and Ajax, I believe it is not only theoretically possible, but truly feasible.
To make an event-driven Web application environment you need three components:
- A DOM event-driven widget library
- An Ajax control framework that manipulates DOM widgets, and passes and interprets XML messages
- A server-side framework that exposes Ajax-generated events and messages as a GUI interface, and maintains Web application threads.
Ajax is a programming approach of passing XML messages between client-side scripts and a web server without a full page refresh. The code used to send and receive XML messages is currently rather browser-dependent (W3C, we need your help here!), however, Ajax libraries have been developed to hide these browser issues. An Ajax control framework can be developed to create and manipulate DOM widgets, and send data and events to and from a web server.
Finally, a strong server-side framework is required to link the DOM widgets and Ajax messages to a running Web application. One important challenge is to take the random Ajax-generated events and data, populate objects and awake the appropriate sleeping Web application thread, gather new commands and data from the Web application, and the new information back to the Ajax control framework.
With the combination of these three frameworks, an event-driven application can link to a GUI library and magically work on the Web.
I should note that JavaServer Faces (http://java.sun.com/j2ee/javaserverfaces/download.html) works hard on the server side to make complex reusable GUI components and events, however, a “page submission” remains as a primary concept, leading to large collections of JSP and Servlets bound together by XML configurations. In order to get rid of the concept of a “page submission” it needs the Ajax engine.
So, when can I stop mucking around with JSP or ASP scripts?