The Promise of Ajax and DOM: Simple Event-Driven Widget-Based Web Applications

As a Web developer, I have a confession to make: I prefer writting desktop applications. 

In an enterprise-level Web application, just to get a usable display tier you need to perform gymnastics in JavaScript, CSS, HTML, JSP, Java, and Struts (a similar set of gymnastics is required with ASP).  To create a "widget" that appears to work across multiple page submissions you need to coordinate code segments distributed across multiple JSP and Servlet scripts.  It requires great energy, organization, and complex system architecture diagrams to make sense of the flow of responsibility between classes and pages in a Web application.

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.

DOM is a browser-independent W3C standard that allows script-based manipulation of an HTML page.  It is so powerful that you can create whole window-based interactive widgets within a Web browser.  Take a look at JPWM (http://jpwm.sourceforge.net/demo/) or WinLike (http://www.winlike.net/).  Thanks to DOM, client-side scripts can create HTML elements and react to events.  With DOM, you can create event-driven widget-based client-side applications, but since browsers don't allow interaction with the file system (for security), DOM applications are extremely limited in what they can do by themselves.  In other words, while you can write a word processor in JavaScript with DOM, you can't save the resulting files anywhere!

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?

Comments

[ErommodoNalia]

Work is of two kinds: first, altering the position of matter at or near
the earth's surface relative to other matter; second, telling other people
to do so.
-- Bertrand Russell

----------------------------------------------------------------------------------------------------
http://ebloggy.com/geoffreyreillyaw