Craig McClanahan's Weblog

Friday August 19, 2005

Web App Framework Innovation Continues -- News At 11

As many of you might recall if you've heard me speak about web application frameworks, the fact that (in the early 2000s) there were so many available choices. At one time, during the development of the JavaServer Faces 1.0 spec, I was tracking close to 50 choices in the Java web tier space. While the wide range of choice was very gratifying, it was also very confusing to developers and architects tryng to decide what to use. It was also not optimal for creation of components that could be transferred from one vendor's technology to another.

Among the promises of a standard API for building web tier user interface components was the idea that a common base API would encourage the creation of component libraries that could be used across different vendor implementations of JSF, across multiple application servers, and across mutiple tools. It is pretty clear that, over the almost 18 months since 1.0 went fnal, that we (as an industry) are well on the way towards seeing this vision turn into reality. There is widespread innovation all over the JSF landscape -- not just in components, but also in non-HTML renderkits, non-JSP view technologies, and customizations to the basic JSF front controller framework. The latter (of course :-) has been of particular interest to me; more about that below.

So, did the emergence of a standard API stifle innovation in this field (a potential downside that detractors of standards efforts sometimes pose)? Not hardly. It's definitely true that the number of frameworks you hear a lot about is smaller now, but the pace of innovation (as well as applying "lessons learned" from the successes, and failures, of older frameworks continues apace. Today, then, we're still in a world where a development team has a variety of technical choices to base their architectures on. How do you choose?

For one portion of the population as a whole, this decision will (at least in part) be based on how well a potential framework plays with the standard API (JSF). People concerned about this will recognize that JSF 1.2 is now a required part of the Java EE platform (as of verson 5.0), and might be concerned about staying in reasonable alignment with the mainstream standards. If this is you, then you will likely find yourself categorizing various frameworks on their degree of closeness with JSF. The following dimensions will serve as a useful starting point:

• Frameworks that can use JSF components as an alternative view representation. This will be the broadest category, because basically all the interesting frameworks can use the RequestDispatcher.forward() mechanism provided by the Servlet API to forward to either a JSP page, or some alternate JSF view handler supported technology, to render the actual view. In such an environment, you typically do not see other features of JSF (conversion, validation, navigation, managed beans) being used -- instead, the native capabilities of the framework, which are also used when JSF is not present, are utilized. Instead, the output features of the components are the primary value received by using JSF.
• Frameworks that utilize more of the input processing capabilities of JSF. In addition to using JSF as an output technology (as described in the previous category), various frameworks can use portions of the input processing capabilities as well. Just as one example, if you use Struts with the Struts-JSF integration library, you can use the automatic type conversion feature of JSF input components to make your form bean properties typesafe, and therefore not have to do tedious conversions in your action methods.
• Frameworks that use JSF as a foundation, adding value via the extension points in the APIs. Such a framework will leverage the fact that JSF itself provides a standard MVC-based front controller architecture (with a well defined request processing lifecycle), plus other application oriented features (such as managed beans and navigation management), in addition to its component API architecture. Such a framework can therefore be simpler to build and maintain, by avoiding the redundant implementation of features already provided by JSF, and focus on adding value (additional features, improved ease of use) around the edges.

  Shale is the only framework I am aware of that currently fits into this category -- if you know of others, please comment on this blog entry with pointers.

For people where alignment with JSF is less important, or not at all important, it is still somewhat difficult to compare the various approaches, because they appear (on the surface) to be so different from each other. To assist with this sort of a comparison, I presented a session at the recent O'Reilly Open Source Convention (thankfully, in my home town of Portland so I didn't have to travel for once) laying out a basis for comparing web application frameworks focused on how they address the following major architectural decisions:

• Overall application architecture
• Representation of static and dynamic markup
• View tier component model (or not)
• Mapping requests to business logic
• Model tier resource access
• Page navigation

In the slides, I compared the following frameworks on these decision dimensions:

• Struts
• WebWork
• Spring MVC
• Tapestry
• JavaServer Faces

No, this does not cover the entire gamut of interesting frameworks -- but I only had a 45 minute slot, and we still had to race through the slides very quickly to get through in only three minutes over my alotted time. But the interesting thing was to see where the different frameworks approached the same problem area in a similar manner, versus where they took divergent approaches. Seeing how the covered frameworks compared on these categories should make it easy for you to do a similar analysis of other frameworks, if that is your desire.

Interestingly, the standardization of JavaServer Faces did not kill innovation around other frameworks (or even stop people from trying to create and introduce new ones). Indeed, one could argue that the finalization of the standard API was a catalyst that triggered a renewed burst of activity on the part of many framework developers, knowing that all of the frameworks would now be compared to "the standard" approach.

It is also pretty clear that JavaServer Faces has hit a sweet spot where innovation around the standard itself can also grow rapidly. You can see in the comparisons that the expert group which created the 1.0 version of the spec did indeed harvest many lessons from the other frameworks that existed at the time, as well as recognizing that we had to provide robust extension points to allow innovation to occur on top of this standard. And it has been. And it is continuing.

There were those who thought that the Java web tier was going to become a boring place as more and more technologies got standardized. I don't think we have to worry about that for a while yet.