Problem: JSP Unfriendly to Component-Based Frameworks
JSP is the primary view choice for JSF apps, but it's clunky at best. Most frameworks that use JSP simply render values as they encounter them when loading a page. Relationships between portions of a page will only occur at the HTML level, rather than on the server-side.

JSF has a different model - it builds a component tree when a page loads. JSP adds page components to the tree in the order they appear on the page. This makes it difficult to create relationships between components, such as labels and input fields. To work around this, you can wrap your forms with an <h:panelGrid> tag, but then you have to remove any HTML from your form (or wrap it with an <f:verbatim> tag). You end up with a JSP page that doesn't have a single line of HTML in it. In other words, you're back to the pre-JSP days with JSF, where Java code, rather than HTML authors produce the entire HTML.

Solution: HTML Templates
The good news is that JSP isn't the required view technology for JSF. It was simply chosen because of the proliferation of JSP-based apps and because so many developers were familiar with it. JSF 1.2 lets JSF use HTML Templates like Tapestry does. These templates will either reuse existing HTML attributes (such as id), or add an additional one (such as jwcid). Hans Bergsten provides an example of this in his "Improving JSF by Dumping JSP" article. An Open Source project called Facelets (http://facelets.dev.java.net) also implements such a solution.

JSF doesn't just render HTML; that's just one of the possible render kits. In theory, it's possible to create render kits for all kinds of view options: XUL, J2ME, or even Laszlo.

The Future of J2EE's Web Tier
The future of J2EE's Web Tier depends largely on JSF - at least from a standards perspective. However, many popular Open Source alternative Web frameworks are available, such as Spring MVC, Struts, Tapestry, and WebWork. These frameworks have already helped shape the future of J2EE's Web Tier. JSF incorporates many of the ideas and features of Struts. The managed properties of a JSF Managed Bean are very much like Spring's Dependency Injection. A JSF Managed Bean looks very similar to a WebWork Action. JSF mimics many of the concepts in Tapestry to enhance its ease of use, such as a rich set of components and HTML templating. Furthermore, all of these frameworks are part of J2EE in a sense, since they build on top of J2EE's Servlet API. Without J2EE, these frameworks probably wouldn't exist in their current form. Likewise, J2EE wouldn't be where it is today without these frameworks and the innovation and competition they've provided.

Having choice among frameworks is a good thing because it forces framework developers to innovate and compete for users. Not only do the different frameworks show different ways of doing things, but they're also borrowing from and competing with one another to become better. Competition breeds innovation. J2EE stands to benefit from this innovation because the good ideas can be added to JSF and the bad ones can be removed. The Java Community Process and Expert Groups for J2EE and JSF are very open to the community, so the community will contribute and help improve it, much like they have with the many Open Source alternatives.

All of the frameworks mentioned do the same thing, just in different ways. JSF and Tapestry are making developing Java Web applications easier due to smarter defaults and better plumbing. They don't require the developer to know much about the Servlet API, and they handle most input types transparently - without using custom converters. Furthermore, their concept of components lets developers create reusable components that they can use with only a few lines of code.

The future of J2EE's Web Tier isn't one of self-determination. Many other factors will play into the success of a standardized Web framework. J2EE and its developers can ensure its continued success on the Web by being willing to adapt. As a community, we need to continue to recognize good technologies and ideas from experienced developers and Open Source projects. We need to be willing to support remote scripting with Ajax, and we need to adapt to produce rich-client experiences, like those that Laszlo offers with the Open Source Flash-rendering system. By accepting and enhancing these technologies, we can continue to use J2EE and its APIs to make our lives easier. By developing more efficiently with the best technologies available in Java, we can continue to produce satisfied customers.