Picking the "right" library for your app is a painful process, especially when developing the UI. Will it be robust enough, will it be maintainable, can my team use it effectively, and in what form will the library be in a year from now?  I will talk about using an agile team to develop two versions of an enterprise application. The first version was strictly Javascript, initially Ext-JS, then completely custom Javascript. In an effort to support new developer productivity and maintainability a second version was implemented, totally redesigning the UI using JSF 2.0.

Project

The project is the Assurance Information System(AIS), designed to assist in tracking and documenting of risk across the complex. An agile team of six developers worked in two week sprints with daily stand-ups. The team had varying levels of experience in Java, only one had experience with JSF. Two members had experience with Java-based Struts. Overall, there was limited experience with Javascript libraries. As the team lead, I have worked on projects using the following Javascript libraries: YUI, Dojo, JQuery and Ext-JS, as well as JSF 1.0, the Java-based GWT, and Struts. 

Both versions of the Assurance Information System(AIS) are deployed on Weblogic 12c and use MS SQL Server. The first version used straight JDBC and the second version used JPA 2.0. An external group had been engaged to create a UX design. The first UI module, completed over one year,  started with the Javascript library Ext-JS, and then moved to a completely custom Javascript library.  A custom approach was pursued because it was assumed that the current Javascript libraries could not support the UX design. Every component was built from scratch. The team struggled to work with the library. It was difficult to maintain and the learning curve was significant.

For the next version, we decided to use JSF 2.0 (ICEfaces 3.1) to implement the same UX design. Very little was carried over from the first version. All front end work was now in the form of XHTML pages rather than Javascript and JSPs.  The team readily picked up JSF development with no formal class training. An agile approach required that we had something to demo at the end of every two weeks. This supported learning JSF very well since the team could start by working with very basic pages. As the development progressed, the team was able to get up to speed with more extensible page layouts using composition pages. Several of the team members thoroughly embraced developing composite components.

Productivity was further enhanced by developing in a team room, no cubes, no walls, lots of white board and a few very large screens for group discussions. Since most of the team had neither JSF or JPA experience, the team room facilitated rapid exchanges of information. All primary development was done within each developer's Eclipse environment. Hudson deployed automated builds twice daily to a development server.

Pros/Cons

There is not much you can't do on a web page with Javascript. Like C++, Javascript is also very dangerous if the developer is not very disciplined. Unlike C++, you might not see an error with bad Javascript in the browser.  Even if you do, it may not be obvious what is wrong. To make matters worse, different browsers behave differently.  The debugging tools in Chrome and Firefox are great. This helps but it all leads to a need to minimize how much custom Javascript you create. 

Most JSF libaries leverage the power and stability of mainstream Javascript libraries like JQuery to offer more advanced functionality than simple HTML components. If you are really adventurous and discipline, you can create any Javascript component you can think of, wrap it in JSF, and interact with it the same way you would any other JSF component. A lot of you out there would cringe at the thought of wrapping perfectly good Javascript in something as heavy weigh as JSF.  We did not experience a performance hit when we moved from the Javascript-based version of AIS to the JSF-based version. There is quite a bit of traffic between the browser and server, but the user experience was never compromised. With JSF 2.0, dropping the use of JSPs has greatly improved the performance.

JSF provides a standard interface to interact with any component no matter what the underlying library might be. It takes away the grunt work of hooking components up to your back end—no more manual processing of AJAX calls.  The first version of AIS wrote quite a bit of marshalling code in order to interact with the server.  With JSF 2.0, you access  the bean object directly in your XHTML page. What a concept! All of this leads to a more consistent development team experience, one that is more easily embraced by all team members and future maintainers.

JSF got a really bad rap because JSF 1.0 was not ready for prime time. Developers are not a forgiving bunch. JSF 2.0 is a vast improvement. Is it perfect? Definitely not. Applying and integrating custom CSS styling is always a challenge. It is with Javascript too. The main reason for going with custom Javascript in the first version was because it was assumed that it would be too difficult to support the UX design. For version 2, it was pretty straightforward to apply JSF 2.0 to an enhanced UX design. The team was not constrained and the customer was very happy. The productivity improvement between the Javascript-based first version of AIS and the JSF 2.0-based second version was incredible, both in development and debugging.

The adoption of JSF 2.0 is still pretty small by comparison to the mainstream Javascript libraries. Using JSF ties you to Java. Javascript does not restrict you to any environment.  However, for an enterprise group, management is always pushing for stability, re-usability, and the ease in which new team members can get up to speed.  You are not going to get experts or even really advanced developers in this market. The reality is you work with what you have and build skill sets as the project progresses. The success of your project and your team's satisfaction is dependent on a development environment that works. And JSF 2.0 has worked for us.

Conclusion

For every one developer that is working at a Facebook there are 10 developers working in a corporate IT shop. Corporate management wants consistency, not the bleeding edge. They want it to work and they want their development teams to be effective.  They want deployed applications to be maintainable. Our experience clearly showed that JSF was significantly easier for new members to become productive in. We showed that given complex UX designs, JSF could readily support both form and function.  Either JSF 2.0 or Ext-JS could have been used to implement the design. However, the team would not have been as efficient and satisfied using Ext-JS as they were with JSF 2.0.