The Artima Developer Community
Sponsored Link

Leading-Edge Java
Rich-Client Misconceptions
An Interview with Adobe's James Ward
by Frank Sommers
May 6, 2008

Advertisement

Summary
Rich clients are more than just about user interfaces, argues Adobe's James Ward in this JavaOne 2008 interview with Artima. Rich clients are about architecture, and are also about collaboration between developers and designers.

While the most obvious characteristic of rich-client applications are their user interfaces, rich clients are about much more than just UI development. In this interview with Artima, Adobe's James Ward points out that rich clients often require a different architecture from traditional Web applications. In addition, Ward notes that creating a rich user experience means that developers have to work closely with designers, and that development and design tools and methodologies must seamlessly integrate to be effective:

There is a major shift going on now towards rich Internet applications. While rich Internet applications at first appear to be about a rich user interface and a rich user experience, they also have fundamental differences in terms of architecture and development process from traditional Web applications.

Because relatively few developers have built rich Internet applications yet, there are several misconceptions about rich-client apps. One big misunderstanding is that rich Internet applications are just about animation and fancier UIs. That's certainly a piece of it, but they're more about moving almost back to the client-server architectures, but with much more capable tools that we ever had for doing client-server development, and now, of course, doing client-server across the Web.

With rich clients, you have an actual application on the client: there is state on the client. We have a three-tier architecture with a stateful client, a middle tier for possible business logic, and your database. Those are three distinct tiers, whereas in a typical Web application, there is a pretty tight connection between the Web application and the app server, and the browser is just a dumb rendering device. Rich Internet applications try to leverage the client more, do more on the client, and that results in a cleaner separation of responsibilities.

There is also a misconception that rich Internet applications take a long time to build, and that they require considerable investment and effort. That may be true for some technologies, but from what we've seen in Flex, people are significantly reducing the amount of time they need to spend building software in general, not just rich Internet applications.

I just heard one case recently where someone in healthcare began building a rich Internet application on Flex. They started out with five people. Now they're up to about eighteen people, and in two years they've released in production an application that competes with an Ajax application built by over a thousand engineers over five years. That's a pretty dramatic difference, but not surprising.

The notion is that rich Internet applications take more time than traditional software to build, but we're seeing the opposite, in fact. Not having to deal with cross-browser and cross-platform issues is just one reason for that, but another reason is that you get to leverage your existing infrastructure. Some teams are spending up to thirty percent of their development time just dealing with cross-browser compatibility issues. That has even led some enterprises to support just IE, which is really unnecessary and unfortunate.

Another common misconception is that it's difficult for designers and developers to work together so that you can create a great design and developers can actually implement that design. Using Flex, one of the great things is that many designers are already using the Adobe products to do design. They're using the Creative Suite products, Photoshop, Illustrator, Flash, and so on.

We built plug-ins for all those tools that allow designers to build the look and feel for a Flex application. In Flex Builder you can just go and import those assets into your application and use those assets that the designer has created. That helps the actual application looking what the designer had intended. If you look around, many Flex application are heavily designed, and it's not a lot of work really, and certainly not a lot of developer time to implement those designs.

What do you think of the current state of developers working with designers when building Web applications? Do you agree that rich-client technologies, such as Flex, make that collaboration easier?

Resources

James Ward's Blog:
http://www.jamesward.org/wordpress/

The Flex Community home page
http://www.flex.org

Post your opinion in the discussion forum.

About the authors

Frank Sommers is Editor-in-Chief of Artima Developer. He also serves as chief editor of the IEEE Technical Committee on Scalable Computing's newsletter, and is an elected member of the Jini Community's Technical Advisory Committee. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld.



Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us