How would you address these issues with JSF? Could you make the same lists for other frameworks? how would they look? Would they be as legitimate?
- Extra step when defining a project's architecture
- Fragmented Community
- Fragmented Documentation
- Component Incompatibility
- Caveats on some scenarios because of different implementations
- Designers and developers roles mixed
- Does not improve usual web development process
- Non-functional prototype
- Web is fast, standards are slow
First, apologies for the long post. :-) Before I respond to the author's points, I would like to say I have been so busy doing JSF development the past few years that I have not kept up with the other web frameworks like Wicket, Tapestry, Struts 2, Spring MVC, Stripes, etc. so I have no basis (or need) for comparison. That said, I find it interesting that JSF, fairly or unfairly, is often the subject of criticism in the web frameworks arena.
Here's my 2 cents. (Disclaimer: I am an independent JSF consultant, JSF trainer, public speaker, author on JSF, and my company builds JSF development tools.)
The author makes some valid points about JSF and I can understand where he is coming from.
1. Extra step when defining a project's architecture.
I'm not sure about this point. I agree with others on this thread; the author needs clarification on the difference between the JSF framework and JSF component libraries. To be fair, it's a jungle out there. It takes time and experience to learn the difference between Facelets, MyFaces, RichFaces, and so on. Like other web frameworks, JSF provides a familiar architecture that developers can build on. The more JSF projects you work on, the more familiar that architecture becomes and the easier it is to build JSF applications.
2. Fragmented Community.
Here the author is saying the JSF has no central community. (JSFCentral.com anyone?) He seems to dislike the idea of joining mailing lists, reading forums, and learning to use component libraries. Hey. That's ok. Some people prefer simplicity over choice. With JSF, you can choose between hundreds of UI components to build your project, and this can be overwhelming. Personally I think choice is a good thing. If you're willing to join the mailing lists and get involved in the community it can be a lot of fun.
3. Fragmented Documentation.
I agree with the author that documentation is not centralized, but there are an increasing number of books, tutorials, and reference material available on JSF. Once again the author is confusing the JSF framework and UI component libraries. It helps to have a high-level understanding of how these different technologies fit together. JSF is like a car; UI components are your power steering, V8 engine, heated seats, sunroof, etc.
4. Component incompatibility.
This is a valid point, and I'm glad the author acknowledges that JSF 2.0 is addressing the main interoperability concerns of JSF 1.x components, not the least of which was Ajax library conflicts. Using the car analogy, in practice JSF libraries are more like "conversion kits" that can substantially upgrade your vehicle. There is a certain amount of overlap here, especially when it comes to Ajax. Once again it helps to know your MyFaces Trinidad from your JBoss RichFaces and to understand when, where, why, and how you would use a particular component library and make an informed decision about the right combination of JSF technologies for your proejct.
5. Caveats on some scenarios because of different implementations.
Implementations of what? The two most popular JSF implementations, Apache MyFaces and Sun's JSF-RI (Mojarra), are largely interchangeable. So what we are talking about here is UI component library interoperability. Yes, it helps to know which libraries are compatible but this takes time and experience. Fortunately this is a road that many developers have travelled. It shouldn't be hard to get information and advice from... mailing lists and forums. :-)
6. Designers and developers roles mixed.
Actually, I see JSF as providing an ideal technology for UI designers and developers to work together. I think success in this area comes down to two things: a) having the right mix of talent and experience on a project, and b) having the right tools for the job. As an MVC framework JSF supports separation of concerns and UI design and application development roles can be divided along these lines. I see a lot of opportunity for collaboration between creative and technical people in a JSF environment.
7. Does not improve the usual web development process.
I'm glad the author mentions Facelets here because it does help a lot. JSF 2.0 is based on Facelets, and this is a good indication of where things are heading on the JSF roadmap. Facelets is a perfect alternative to JSP; no more scriptlets, no more spaghetti code, just clean and simple markup. You can author your pages in pure XHTML if you want, or you can use pure JSF markup. It's up to you.
8. Non-functional prototype
You can create non-functional prototypes with HTML and later add jsfc="..." to your HTML tags to convert a static mockup into a dynamic application. Also, prototyping applications requires more than just HTML mockups, e.g. UI design wireframes, UML diagrams, screenshots, etc., so its not resonable to expect a web framework to provide all of this.
JSF can achieve very good performance and scalability in a clustered environment with caching enabled. Add JBoss Seam on the backend and you have the EJB3 container to help you manage server-side resources more efficiently.
10. Web is fast, standards are slow.
My advice to web developers considering JSF is to do your homework before you dive in. If you want to get some experience with JSF before you commit to overcoming the learning curve, definitely start with Facelets and get a feel for how simple JSF can be. As your knowledge and confidence increases you can explore other component libraries and frameworks that integrate with JSF.
I would start by learning how the standard UI components work, then trying out MyFaces Tomahawk to add some useful and interesting components to your projects. Due to its simplicity, Tomahawk is generally very good at integrating with other JSF libraries. When you want to add an Ajax library, there are many good choices, such as ICEfaces, JBoss RichFaces, MyFaces Trinidad, and PrimeFaces. Keep in mind that these libraries are not all compatible yet, so read the documentation carefully and if you have to go with one library pick the one that suits your project and go with it.
JSF is fun when things are working well. One area I think could really help is testing. There are a few unit testing frameworks out there for JSF (e.g. JSFUnit, Arquillian, and others) and these can really help kick start the development cycle. UI testing or functional testing is also important and Selenium is a great choice in this area.
Author, JSF 1.2 Components (Packt)
JSFToolbox for Dreamweaver - www.jsftoolbox.com