JavaServer Faces JSF is a Java specification for building component-based user interfaces for web applications and was formalized as a standard through the Java Community Process being part of the Java Platform, Enterprise Edition. It is also a MVC web framework that simplifies construction of user interfaces UI for server-based applications by using reusable UI components in a page.
JSF 2 uses Facelets as its default templating system. Other view technologies such as XUL or plain Java can also be employed. In contrast, JSF 1.x uses JavaServer Pages JSP as its default templating system.
In 2001, the original Java Specification Request JSR for the technology that ultimately became JavaServer Faces proposed developing a package with the name
By June 2001, JavaWorld would report on Amy Fowler's team's design of "the JavaServer Faces API" aka "Moonwalk" – "an application framework for creating Web-based user interfaces".
Based on a component-driven UI design-model, JavaServer Faces uses XML files called view templates or Facelets views. The
FacesServlet processes requests, loads the appropriate view template, builds a component tree, processes events, and renders the response typically in the HTML language to the client. The state of UI components and other objects of scope interest is saved at the end of each request in a process called stateSaving note: transient true, and restored upon next creation of that view. Either the client or the server side can save objects and states.
Because JSF supports multiple output formats, Ajax-enabled components can easily be added to enrich JSF-based user interfaces. The JSF 2.0 specification provides built-in support for Ajax by standardizing the Ajax request lifecycle and providing simple development interfaces to Ajax events, allowing any event triggered by the client to go through proper validation, conversion, and finally method invocation, before returning the result to the browser via an XML DOM update.
The following companies and projects offer Ajax-based JSF frameworks or component libraries:
Facelets that was designed specifically for JavaServer Faces was adopted as the official view technology for JSF 2.0. This eliminates the life-cycle conflicts that existed with JSP, forcing workarounds by Java developers. Facelets allows easy component/tag creation using XML markup instead of Java code, the chief complaint against JSF 1.x.
The new JSF developments also provide wide accessibility to Java 5 annotations such as
@FacesComponent that removes the need for
faces-config.xml in all cases except framework extension. Navigation has been simplified, removing the need for
faces-config.xml navigation cases. Page transitions can be invoked simply by passing the name of the desired View/Facelet.
Addition of Partial State Saving and DOM updates are part of the built-in standardized Ajax support.
JSF 2.0 also includes a number of other changes like adding support for events, separate development, staging, and production modes, similar to
RAILS_ENV in Ruby on Rails, and significantly expanding the standard set of components.
In their January 2014 "Technology Radar" publication, ThoughtWorks wrote:
We continue to see teams run into trouble using JSF -- JavaServer Faces -- and are recommending you avoid this technology. Teams seem to choose JSF because it is a JEE standard without really evaluating whether the programming model suits them. We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do. JSF, like ASP.NET webforms, attempts to create statefulness on top of the stateless protocol HTTP and ends up causing a whole host of problems involving shared server-side state. We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken. We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS.
In the article published November 2014 in the DZone website, titled "Why You Should Avoid JSF", Jens Schauder wrote:
Facelets, the preferred presentation technology of JSF looks at first sight like an ordinary templating technology like the good old JSP or Thymeleaf. But if you look closer the horror becomes obvious. In the same place where you structure your HTML, you also place the logic what parts of the UI should get updated on an action. A clear violation of the separation of concerns principle in my book. Even better is the immediate attribute which changes the server side life cycle! And if this isn’t enough it does it in different ways depending on what tag you use it on. You can’t make stuff like this up.