Summary
Two distinct approaches to Ajax application development emerged in recent years, each extending previous architecture models. As the two seem incompatible, you will need to make a choice.

When you hear the term Ajax these days, your first reaction might be highly interactive Web pages, and along with that the requirement to code at least part of a Web application in JavaScript to offer that interactivity. While there is agreement on what an Ajax application means, there is much less consensus about how a developer would interact with that JavaScript, or how to distribute display logic between client and server.

In recent months, we reported on Artima about several Java-centric rich-client frameworks that aim to completely hide a developer's interaction with JavaScript. Those frameworks encapsulate JavaScript into JSF components, treating JavaScript almost as an implementation detail hidden from the developer. Taking advantage of JSF's server-side rendering model, JSF-based Ajax frameworks render out a component's state to the client—along with any JavaScript that forms part of that component's state.

By contrast, the Ajax world is abuzz with several client-side component toolkits that take a different approach. Toolkits such as Dojo or Prototype not only expose JavaScript to the user, but make it easier to develop page-as-application type apps. The Dojo Toolkit, for instance, provides many APIs that mimic important parts of the J2SE API, such as collections and validators, in addition to UI widgets. Such an application would place not only display logic, but even some business logic on the client, and that business logic would be coded in JavaScript. Interaction with a server would be limited to situations where the client application must interact with external resources—for example to fetch data into the client, or to save a user's changes to data.

Because the JSF-based Ajax approach performs all rendering on the server, and encapsulates Ajax features into components, it seems to be an extension of thin-client computing, and is thus a direct descendent of traditional Web apps that render simple HTML on the server and then push that rendered component representation—HTML—out to the client. A more remote cousin of this approach is the Sun Ray thin client device that renders desktop images on the server, and pushes the rendered images to dedicated client devices. In both cases, the client is treated not much more than as a specialized display. The second approach, by contrast, is an extension of client-server computing that distributes an application's logic between client and server—only, in the Ajax world, the client is a programmable Web browser.

While both approaches are rooted in well-established practice, they take a markedly different philosophy to application development. Proponents of the thin-client approach mention incompatible JavaScript implementations in browsers, as well as the relative obscurity of JavaScript as a serious development language. They seldom mention whether the thin-client model would be preferred even if all browsers rendered JavaScript equally well.

While JavaScript is still a hard language to develop business logic in, a new version, EcmaScript 4, promises a fully object-oriented language not unlike Java, and because it's fairly standardized, browser implementations will in time converge on fairly compatible implementations. In addition, client libraries already mask most of the browser incompatibilities.

Client side proponents claim that their approach makes better use of local computing resources, and also results in applications that can replace traditional desktop applications, even without a permanent network connection (for example, Dojo, as well as Flex, have client-side storage APIs).

The diplomatic response to this dichotomy of approaches is that each design has pluses and minuses, and that each has its place. But because these approaches are not only different, but also incompatible—adding custom client-side JavaScript to a JSF-based component would venture outside that component's public interface—if you were to develop a brand new rich-client application, you would have to choose either the thin-client approach or the client-server model.

Which approach would you choose, and why?

Talk Back!

Have an opinion? Readers have already posted 26 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.