JSF

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 Java EE standard without really evaluating whether the programming model suits them. We think JSF is flawed because its programming model encourages use of its own abstractions rather than fully embracing the underlying web model. JSF, like ASP.NET webforms, attempts to create stateful component trees on top HTML markup and the stateless HTTP protocol. The improvements in JSF 2.0 and 2.2, such as the introduction of stateless views and the promotion of GET, are steps in the right direction, maybe even an acknowledgement that the original model was flawed, but we feel this is a too little too late. Rather than dealing with the complexity of JSF we recommend teams use simple frameworks and work closely with web technologies including HTTP, HTML and CSS.

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 Java EE standard without really evaluating whether the programming model suits them. We think JSF is flawed because its programming model encourages use of its own abstractions rather than fully embracing the underlying web model. JSF, like ASP.NET webforms, attempts to create stateful component trees on top HTML markup and the stateless HTTP protocol. The improvements in JSF 2.0 and 2.2, such as the introduction of stateless views and the promotion of GET, are steps in the right direction, maybe even an acknowledgement that the original model was flawed, but we feel this is a too little too late. Rather than dealing with the complexity of JSF we recommend teams use simple frameworks and work closely with web technologies including HTTP, HTML and CSS.