Why Web Developers Need JavaServer Faces

There's been a plethora of articles written recently on one of the Java
Specification Requests (JSR) currently making its way through the Java
Community Process (JCP). JSR 127 describes a new technology called JavaServer Faces that, if delivered as promised, will help to further deliver on the Java promise of Write Once, Run Anywhere.

If you've been building Java web applications for a couple of years, then
you should be astutely aware of how the technology has been evolving to make it
easier to write and deploy applications. It started off with Servlets, and then JavaServer Pages were introduced, and we started talking about Model 1 and Model 2 approaches and thinking about
how to use these two technologies together to best leverage the advantages
of each. Taking a snapshot of where we are today, commercial and open source
projects have been formed to put features and functionality around these
technologies. Frameworks like Struts and other web frameworks are getting their due.

Arguably, building web applications is becoming easier, but it's still
cumbersome and frustrating for newcomers. First of all, there's still not a
complete separation of UI from the model. UI designers still have to have some
programming knowledge, and the separation of roles is blurry. Of course, using
components like JSP tags help to focus the responsibilities, but it's still not
perfect. Even if you do use some of the newer technologies like Java Standard Tag Library (JSTL) and JSP Expression Language, you still end up with a UI that's dedicated to a specific client
or channel. What about support for other clients such as wireless devices? Many
Struts applications are built using JSPs that assume the markup language is
HTML. There's no standard approach that's accepted by the entire industry for
supporting multiple clients or channels.

Another limitation is the lack of event handling. In a true MVC model, the
view is able to generate events that can then be handled. For example, when a
value changes in a UI component, the model needs to be updated. How about the
ability for the view to query the model? All of these things are present in rich
clients; just because my application runs in a browser, does this necessarily
mean that I shouldn't have this functionality?

JavaServer Faces attempts to solve some of these issues, and a few others not
mentioned here. JSF prescribes an architecture for projecting the UI to a
client and allowing different rendering kits to render the UI for the specific
client. The state of the components and their values can be maintained on the
server and the UI components can generate events that are handled by the server.
JSF also defines functionality for data conversion, validation, and
localization. JSF promises a bright future for Java web developers -- a future
that should allow for much richer support than what's currently available. If
you haven't started looking at JSF yet, it's time to do so. There's even a Struts/JSF library that's been added to Struts by Craig McClanahan.