Exploring Ajax Runtime Offerings
Pages: 1, 2

A Look at a Few Specific Frameworks

Now I'll take a glance at a couple specific frameworks, placed along these axes. When a framework falls clearly at one end of an axis or the other, it will appear as a circle placed at the appropriate end. When its placement is more ambiguous, I'll try to show a bar to represent its approximate position, and explain further.

Prototype

Prototype is a low-level library of JavaScript functions. Its principal concerns are things like papering over the variations among JavaScript implementations in various browsers, giving the developer enhanced tools to navigate and manipulate the DOM, and providing browser-independent access to the XMLHttpRequest object. A number of frameworks more focused on widgetry have been built on top of Prototype: OpenRico and Scriptaculous are examples in the open-source world, and the commercial JSF framework ICEFaces incorporates Prototype and Scriptaculous.


Figure 4. Prototype

Direct Web Remoting

Direct Web Remoting ( DWR) is a package that's primarily focused on making it easy to marshal data between the browser and a Java Web server (see Figure 5). It papers over browser differences in the client-to-server pipe but leaves the UI concerns to the programmer. It's free and open source, and has an interesting position along the programming model axes: The application programmer defines server-side Java classes, and then the framework generates JavaScript classes that embody the corresponding data structures on the browser side. So I characterize it as mostly procedural but somewhat declarative in the sense that the programmer decorates Java classes with annotations to generate the marshalling objects. Its APIs are located on both client and server.


Figure 5. DWR

Dojo

In Figure 6, you see Dojo, an open-source, client-centric framework that some people use as a comprehensive framework but others adopt just at the lowest layer, for its plumbing features, without using the UI components. The API is for the most part procedural.


Figure 6. Dojo

Backbase

In Figure 7, I show Backbase, a commercial framework that offers both a client-centric version in its Community Edition, and a server-centric one in its Java Server Edition. It wants the application programmer to specify the layout and behavior of the application declaratively (although it also accommodates procedural code), and its widget set is quite comprehensive.


Figure 7. Backbase

Google Web Toolkit

The Google Web Toolkit ( GWT) is a comprehensive framework (see Figure 8). The programming model is server-centric and procedural; the API looks a lot like SWT. This framework has one of the most interesting architectures out there: The Java application code is debugged by running it in the "hosted web browser" tool shipped with the framework. When you want to run the application in an actual browser, you use the framework's compiler to convert the part of the application that will run in the browser to JavaScript, and then serve it into a Web page. The runtime part of the framework is free and open source; the two development tools that come with it (the hosted Web browser and the compiler) are closed source but are free with the runtime distribution.


Figure 8. Google Web Toolkit

Tooling Considerations

The great divide in tooling requirements in the framework space occurs when you cross from the client to the server side. Client-centric frameworks require JavaScript and browser-oriented tools: a JavaScript editor, debugger, and validator, a browser DOM inspector, message tracing, and so on. Two promising sources for these kinds of tools are the Mozilla Foundation, which offers a DOM inspector, a JavaScript debugger, and a host of free add-on plug-ins available from the Internet, and the Eclipse Ajax Tooling Framework (ATF) project, available in prerelease form as of this writing. The ATF incorporates the Mozilla tools, and adds a validator and editor.

On the server side, because the frameworks hide browser programming from the developer, you can use same the Eclipse Java and JSP tooling that you would use for a traditional Web application.

In all this, the thing that has most obviously been missing up to this point is a tool that supports visual page construction. Two very recent developments though, show that this situation is about to change. I'll give you a brief tour of a couple examples of new Eclipse-based tooling that work with runtimes that fall on the server-centric side of the programming model divide. Because these runtimes offer programming models for which relatively mature tooling already exists, the amount of work required to produce functional page construction tools is less than it would be for client-centric frameworks, which have less of an existing base to build on.

The first one is BEA Workshop Studio for JSF, with a small amount of code to adapt it to a specific JSF-oriented Ajax runtime. The second example is GWT Designer, a recent release from Instantiations Inc. that provides page construction tooling for the Google Web Toolkit.

BEA Workshop Studio

In Figure 9, you see a prototype version of BEA Workshop Studio, a tool for building pages visually using Workshop Studio integrated with ICEFaces, a commercial Ajax framework from ICESoft. Since ICEFaces offers a JSF programming model, it can be readily adapted to existing JSF tooling.

The right side of the view is the combined Design and Source view of the page layout. The tool supports full two-way editing: Changes in the Source pane are immediately reflected in the Design pane, and vice versa.

The Tag Libraries palette is located in the lower-left part of the window. Clicking one of the ICEFaces tags in the palette will add it to the source file at the current cursor position, and consequently to the Design view as well. The Smart Editor, just above the palette, understands all the attributes associated with the tag, and helps the user bind appropriate atributes to JSF backing beans.


Figure 9. Workshop Studio JSF Tooling

GWT Designer

Instantiations Inc. recently released a product called GWT Designer, which provides page construction in Eclipse for the Google Web Toolkit. Since the GWT's programming model is mechanically identical to SWT or Swing—the UI is laid out by constructing Java objects and adding them to container objects—and since Instantiations already offered a very rich page construction product called WindowBuilder Pro for both Swing and SWT, they had a solid base ready to build the GWT Designer on top of. In Figure 10, you can see the Design pane of the tool: the design surface on the right, the widget palette in the middle, and a view of the widget tree in the upper left, as well as an editor for all the properties of the selected widget in the property sheet in the lower-left pane. Again, the tool keeps the source and design views in sync, and the user can make arbitrary edits to the source that are preserved throughout whatever changes the user makes via the design pane. Since the programming model for the GWT is pure Java, the designer tool can run using only the base Eclipse installation (no Web tools required), and the Java tooling already present in the platform provides all the error discovery, type system navigation, refactoring, and so on.


Figure 10. Instantiations GWT Designer

Conclusion

The Ajax runtime framework space is currently an embarrassment of riches. There are so many options to choose from that exploring it can be a bit bewildering. Tools for it are following close behind, but, particularly in the client-centric world, these aren't as advanced as the runtime offerings in many cases. Many different considerations are involved in making choices: the suitability of a given programming model to the development team that will work with it, available tools, licensure, cost, documentation and support. The shakeout will clearly continue for some time before it settles down. This article has tried to provide some guidance in exploring the space, the tools for understanding how frameworks compare, and a view of what some of the trends are, even if I haven't been very willing to predict where they will ultimately lead. :-)

References

Gary Horen is the Program Manager for Ajax and Languages on the BEA Workshop team