Web Forefront

JSF's relevance in the web-tier compared to JSP's and Servlets, is due to the fact that it addresses many of the shortcomings that were not touched upon by the designers of these earlier technologies, and of course, that its a formal specification developed by Sun, compared to the Java grassroots frameworks that were created to address JSP's/Servlets. Although the last point 'spec vs grassroots' may be questionable as far as effectiveness, that's another issue all together.

JSF's primary objective is to define standardized user interface components, an approach that brings various advantages to Java development on the web tier. Prior to JSF, defining elaborate yet common pieces to make up a user interface, such as menu lists, calendars or forms, had to be done in either two forms: JSP Tags/JSTL or writing the code from scratch.

The benefit of using JSP Tags/JSTL is that through a simple markup string with a few configuration parameters, you have the ability to generate an elaborate piece of your user interface. If you search the Internet for these types of tags, you will find hundreds of them offering everything from widgets to clocks.

However, the biggest issue with this approach is that it proves extremely difficult to mix and match elements, especially between diverse projects. And it is through JSF that the foundations are set for defining a common footing for UI components, a boon for tool users, since the mechanics for auto-generated UI code are standardized.

Obviously, the JSF standard provides a few more functionalities to make it a compelling technology. With UI components standardized, the door also opens for creating multiple delivery markups from the same component, in other words, a Calendar component can be transformed into either HTML markup for a browser, WML for a Wireless device or some other variants.

Another area JSF tackles is hooking client side events to server side code, think data form validation or information updates triggered by mouse. In a classic JSP or Servlet design, you had to jump through various hoops -- or use a framework -- to tie a client side event to execute a particular piece of server side logic, where as JSF has this fully supported. NOTE: This is actually not AJAX , while AJAX does tie client side events to server side logic, it does so without refreshing the whole interface, while the JSF functionality is a mechanism that does require a refresh. Both approaches offer the same end result, but each one with its own advantages and disadvantages.

Obviously no standard can meet the needs of every user, and in JSF's case, various supporting frameworks have already emerged. One such frameworks is Shale , which is actually a second generation Struts -- one of the first frameworks for JSP's and Servlets.

But while JSF may promise on delivering very much needed features to the J2EE web tier, one has to admit that JSF is playing catchup with its counterpart : .NET Web Controls. Many on the things JSF achieves, have been present since version 1.0 of the .NET framework, while J2EE has gone through three major development cycles to achieve the same results.

JSF's current implementations are those provided by Sun which is known a JSF's reference implementation and an Apache project named MyFaces .