Web 2.5

I've always considered myself a "server guy" - working on server-side infrastructure and tooling for enterprise-scale application development, with Java as the programming language of choice in recent years. Client-side UI development, Web UIs in particular, always seemed less challenging. Writing HTML markup and scripting was for "designers" whose focus was on aesthetics rather than heavy duty coding. The heavy duty coding was done by the so-called server guys who provided nicely encapsulated business logic "beans" that designers could consume easily through simple scripting and without much knowledge of programming constructs. Currently popular Web UI development frameworks such as Java Server Faces (JSF) have promoted such a separation of concerns. JSF is fundamentally server oriented (the user interface code runs on the server) and provides separation of the roles of "page authors" writing markup and "application/component developers" writing server-side Java code.

Then came the Web 2.0 revolution. Rich Internet Applications (RIAs), the principal component of Web 2.0, are everywhere. Applications based on AJAX, the umbrella term for technologies associated with building Web 2.0 RIAs, are becoming increasingly sophisticated. The appearance a couple of years ago of revolutionary applications such as Google Maps perhaps triggered interest in more traditionally server-side developers to start working with Web 2.0 AJAX client applications. A larger community of developers taking on the challenge of building Web 2.0 RIAs has resulted in more innovation and wider adoption. In addition, it has changed much of our traditional thinking on application development for the Web.

The fundamental paradigm shift with Web 2.0 RIAs is the moving of more processing away from the server and on to the client. Rich interactivity in RIAs is provided by more client-side execution of business logic and by portions of the application being able to asynchronously communicate with the server and update their state. This paradigm shift has not been a result of any new technology breakthrough, rather a result of factors such as more developers discovering the exciting possibilities of DHTML and JavaScript, and the increased penetration of broadband internet connectivity among consumers. So as more processing moved from the server to the Browser client, what has it meant for the way we build these Web 2.0 RIAs? Well... a lot of pain! The pain is related to three principal factors - client-side component and event models, browser compatibility, and enhanced graphical capabilities.

When software modules reach a certain level of complexity, they require formalized models and frameworks for developers to work with to be effective. With JSF, for the first time we had a formalized component and event model for building Web UIs that we never had before. However, JSF's model is a server-side model. There is no formal, standardized client-side model defining component and event contracts, with frameworks for managing component lifecycle and event handling in the client. As a result most RIAs work without any formal client-side models. Coding complex client-side business logic in RIAs typically involves JavaScript code manipulating an XML/HTML DOM tree rather than invoking client component APIs. With multiple elements of an application asynchronously interacting with the server, having an element of the application coordinate with, and react to, events triggered by other elements often involves intimate knowledge of the internals of other elements. All this results in code that is difficult for developers to write, debug and maintain beyond certain simple applications. For a server-side developer in particular, coding with loosely typed scripting against a XML DOM tree is disconcerting compared to working with statically type-checked, fully object oriented Java code using strongly typed objects and formal APIs.

The second pain point is all too well known - getting a Web application to work consistently across Browsers. With JavaScript implementations that are still different in different Browsers, and RIAs heavily using JavaScript, managing the quirks of each Browser implementation is a major challenge requiring significant development and maintenance effort. This is particularly unsettling for server-side Java developers who take the "write once run anywhere" paradigm for granted.

The last pain point is related to building better graphical capabilities in user interfaces. RIA UIs are increasingly becoming less text oriented and more graphical. Popular Finance applications provide sophisticated graphical data visualizations, with greater ability for users to interact with the data. Even traditional "shopping cart applications" employ more graphical capabilities in helping consumers visualize and interact with products they buy. This enhanced interaction involves things such as sliders for moving the window of data to visualize, 3-D views of products and charts, rotation of a views for alternate perspectives, real-time data push to clients with animated update, use of audio and video etc. It is safe to assume that this trend will continue to grow as users get accustomed to rich graphical capabilities in the interfaces they use. The challenge in today's Web 2.0 RIAs is related to the difficulty in building such capabilities into applications without sacrificing performance. The Browser compatibility issue mentioned before is perhaps even more of a problem when attempting to do vector drawing and animation in the Browser.

Several commercial and open-source AJAX frameworks exist today that attempt to address the pain points described above. While many have done a reasonable job, two fundamental problems remain. One is the fact that these frameworks typically are not directly compatible with each other. Due to the lack of any client-side standards, plugging in AJAX widgets from multiple vendors within an application and having them interact with each other is not an easy task. The second and more fundamental problem relates to the inherent limitations of the JavaScript runtime in the Browser. AJAX frameworks that have attempted to create a "thick client" in the Browser with complete component/event models and client-side state have suffered from performance issues when trying to scale from basic Web pages to larger full-blown applications. It is unlikely that this fundamental limitation is going to go away in the immediate future.

So are we then doomed to just living with these limitations of building Web 2.0 RIAs? Is there a better solution? Yes, there is. It appeared to me as a flash while prototyping with Adobe's Flex framework for building applications that run in the Flash player in Browsers. The pain points mentioned above don't exist when building in this environment. With Flex components, one works with a formal client-side UI component and event model, data model contracts, and MVC-based patterns. With the object-oriented ActionScript 3.0 language, one can work with strongly typed objects, static type checking, interfaces and implementation classes, formal API contracts, polymorphism and exception handling which feels natural for a Java developer. Service calls to the server from the client are by definition asynchronous and don't require any special coding. The AMF3 message format used in the communication between the Flash Player and a Java server provides an efficient binary mode of exchanging information without being forced to using verbose and inefficient text-based formats. With remoting and data service facilities, plugging into a Java back end is a breeze. The Flash Player frees the developer from having to code for compatibility with all Browsers. The ubiquitous nature of the player in consumer and business machines provides a standardized, pre-installed runtime. But above all, the most significant factor is the superior runtime - the Virtual Machine in the Flash Player that executes bytecode generated by compiling ActionScript code. The new ActionScript Virtul Machine (AVM2) in Flash Player 9 with its JIT compiler provides compelling performance. It is possible now to build "thick" client applications running in the Flash Player that can provide satisfactory runtime performance. Flash has graduated from being a channel for "intro screen" multi-media content rendering to a viable medium for full-blown enterprise applications. The graphical capabilities within Flash are of course well known - after all that has traditionally been the sweet spot of Flash. The fact that popular Finance sites offering stock charts render Flash versions is testimony to the superior capabilities of this channel for such graphical content.

I find building with the Flex framework for the Flash Player a significant step forward in the evolution of Web 2.0 RIA development. Microsoft's Silverlight (formerly WPF/E) may provide a similar channel in the near future although we're unlikely to see any easy integration with Java back ends. JavaFX may facilitate similar capabilities for building RIAs sometime in the future (re-incarnation of applets). I call this evolution to the next step Web 2.5. Web 2.5 is not a revolutionary new breakthrough (that's why it is not Web 3.0!), rather an evolutionary step up. Web 2.5 is building the same Web 2.0 style applications without all the pain. Web 2.5 is large complex applications being able to provide more intuitive, interactive, graphical, responsive interfaces to users. Web 2.5 is building "thick" Browser-based client applications that can perform. And with Web 2.5, even us server guys can whip out sizzling Web UIs!