Inspired by some of the recent buzz about filthy rich clients, I decided to take a more thorough look at one of the more interesting rich-client technologies, Flex. Flex is a client development library, and while not open-source, the Flex SDK is available as a free download from Adobe. Flex applications are compiled into a bytecode format that runs inside a virtual machine that's part of Adobe's (formerly Macromedia's) Flash player. Thus, Flex applications come closest to the original vision of Java applets.

As a long-time Swing fan, I always thought that the applet model's promise was never fulfilled. Thus, I looked with envy at the VM-based Flash runtime, a feeling further exacerbated by some of the more snazzy Flex applications that incorporate multimedia in a way I had seldom seen in Java applets or applications.

Recent articles pointed out installation difficulty of the Java runtime as the main reason applets never took off as a popular rich-client medium. While a valid point, installation complexity alone doesn't explain the relative obscurity of applets. JRE installation became much easier since at last JDK 1.4, and while installing the JRE is certainly more involved than installing the latest Flash runtime, Sun has made great inroads into having the top PC vendors pre-install recent versions of the JRE. Although I was not able to obtain any market share numbers from Sun or from other sources, there are plenty of desktops well-equipped to run Java 5-compatible applets.

A more plausible reason for why few developers think of Java applets as an attractive rich-client technology has, I think, more to do with the fact that developing applets, and developing with Swing in particular, is very labor intensive: A lot of code needs to be written to affect basic tasks required of even modest Swing applications or applets. Those tasks go beyond drawing a user interface—most applications must access back-end data, for instance, manipulate data in some way, and provide the user with visual cues or capture input in ways that make sense in the context of an application's data.

To be sure, the Swing APIs to accomplish all that are there. And, indeed, stunning Swing applications have been built. But the price of benefiting from the latest Java client APIs is the need to write a lot of code by hand. I contend that a developer wanting to develop a non-trivial applet or Swing application has to write more code than a server-side UI framework would require for an application with similar features.

In comparison with Swing, Flex feels much like Ruby on Rails feels in comparison to J2EE (especially pre-J2EE 5). While recent server-side Java frameworks have been making great strides towards increased developer productivity, client-side frameworks, and Swing in particular, have been slow to follow suite.

Some months ago, Bill Venners noted in his blog post, Code Generation: The Real Lesson of Rails, that Rails' real lesson is that it makes extensive use of code generation in order to minimize the amount of code a developer has to write by hand. In some respects, Rails can be viewed as a domain-specific language for building Web applications. In a similar vein, Flex can be viewed as a domain-specific language for rich-client user interfaces.

While one can argue with the decisions Flex's designers followed in implementing a declarative user interface markup language in XML, and especially with the decision to rely on a mix of XML and ActionScript code as a way to customize user interfaces, at its core, Flex defines a language targeted at building client applications with minimal code. Once a user interface is defined in that DSL, the Flex compiler generates ActionScript code from the DSL markup, and then compiles that generated code into Flash bytecode in a second compilation phase.

To paraphrase Bill Venners' earlier blog post, the real lesson of Flex is just how potent code generation is as a tool to increase programmer productivity. A common client-side programming task, for instance, is binding user interface components to object properties (so that when a user types a string into a text box, an underlying data model's appropriate property changes to that newly entered text). While various Java frameworks exist to help with that task, and even a new JSR is in the works to address data binding, none of the proposed Java solutions are as simple for the developer as Flex's data binding. The reason is that Flex uses code generation from a DSL to implement data binding. A developer can simply mark a class, or properties of a class, as Bindable, and the Flex compiler's first pass will generate the voluminous boilerplate code needed to observe changes in that object or property.

Flex introduces code generation into higher-level user interface features as well, such as, for instance, the definition of various view states, data validation, and even network communication. The effect of those is that a feature-rich user interface can be constructed with minimal hand-written code.

To be sure, every DSL-based framework has its limitations and rough edges, and Flex is perhaps no exception. But if Swing can learn one thing from Flex, it is that domain-specific-languages can work well for user interfaces. And Flex is not the only user interface framework to prove that point: Chris Oliver's Form Follows Function (F3) is a promising attempt at an even higher-level UI DSL.

As I learn more about Flex, I will post more tidbits about its code-generation features. For now, though, what do you think of the role DSLs can play in user interfaces? If you had a concise way to define Swing UIs, would you be more likely to develop rich-client Java applications?

<define tag="button">
  <argument name="name" />
  <argument name="height" />
  <argument name="width" />
  <transform>
    Button ${name}Button = new Button();
    ${name}Button.setHeight(${height});
    ${name}Button.setWidth(${width});
  </tranform>
</define>

<button name="save" height="20" width="100" />

Button saveButton = new Button();
saveButton.setHeight(20);
saveButton.setWidth(100);

<define tag="standardButton">
  <argument name="name" />
  <transform>
    <button name="${name}" height="20" width="200" />
  </transform>
</define>

<define tag="call">
  <argument name="object" />
  <argument name="arguments" />
  <transform>
    ${object}.${method}(${arguments});
  </transform>
</define>

<defineTransform button <name width height>
  ~<begin
     <var $name <new Button>>
     <$name setHeight $height>
     <$name setWidth $width>>>

<button saveButton 100 20>

<button saveButton 100 20>

Dialog ui = new Dialog {
    text = "this is a dialog",
    new Button {
        text = "Hello world",
        click = () {ui.close();}
    }
};
ui.run();