At Devoxx conference last month, Matt Raible compared JVM Web Frameworks and posted this score matrix. Matt also posted posted baed on what the score was calculated. I met Matt for the first time in March 2010 during TheServerSide Java Symposium in Las Vages.
As someone who has been working with JSF and RichFaces for long time, I wanted to review and post feedback with regards to Matt’s grades for JSF. I also want to be upfront and tell you that I didn’t attend his session. I was at the conference but attended a different session. My goal is not to strike a debate or increase any scores for JSF, but just to show an alternative side as well as potential feedback and comments. Here we go.
To make it easier, I used the following format:
Category – score
Score context (copied from this page)
Developer productivity – 0.5
Score context: 0 if no save/reload functionality, 0.5 if provided by JRebel, 1.0 if built into framework.
JSF Facelets allows you to save/reload in most cases.
Developer perception – 0.0
Score context: 0 if users are unhappy with the framework, 0.5 if there’s some positiveness, 1.0 if they love it.
I know many people who are perfectly happy with JSF. JSF is of course not perfect, but then what is? I’m guessing a large majority of people who are unsatisfied with JSF most likely don’t know how to use it. Just to prove my point further, entire conferences were organized around JSF such JSFDays (now con-fess.com) in Vienna and JSF Summit in the United States. Not to mention other popular conferences with JSF related content such as JavaOne, JAX, WJAX, Jazoon, JBossWorld, TheServerSide Java Symposium, Herbstcampus.
Learning Curve – 0.5
Score context: 0 if difficult to learn, 0.5 if easier, 1.0 if can learn in a day. Struts 2, Spring MVC and others are easy to learn (for me) == 1.0. Wicket, JSF, Tapestry require you know more than just Java web development knowledge == 0.5.
I don’t know what Matt means by “more than just Java web development”. In JSF, as well as Struts 2, Spring MVC you need to know how to use tags, configure objects in XML files (or annotations) and HTML.
Project health – 1.0 (updated from 0.5)
Score context: Releases in 2010, mailing list traffic, books, tagged questions on Stackoverflow.com. Ranked where 1.0 means healthy, 0.5 means OK, but not as good as others, 0 means declining health.
In this file JSF project health has been updated to 1. JSF project health is strong with very active community and 3rd party component eco-system. In general, I’m not sure how fair it is to base project health on a Q&A type site like Stackoverflow.com
Developer Availability – 1.0
Score context: Rating based on number of developers with the framework listed as a skill on their LinkedIn profile.
There is definitely a good supply of developers with JSF skills.
Job Trends – 1.0
Score context: Rating based on number of jobs on Dice.com, as well as job trends from Indeed.com.
With JSF 2 being part of lightweight and upgraded Java EE 6 platform, I’d anticipate the demand for JSF developers should only increase.
Templating – 0.5
Score context: Rating based on the number of UI templating options are available for the framework. For example, a framework that can use JSP, FreeMarker and render in PDF and Excel is much higher than a framework that only does JSP. JSF scores 0.5 because Facelets is only option.
JSF and the community moved away from JSP simply because it wasn’t a good match for JSF. Facelets is an excellent technology. Purely basing this score on the number of supported technologies is probably not the best approach. In theory JSF also supports JSP, but no one is using it. I think it would be better to look at this from the perspective if the particular UI templating technology makes development faster and easier than just numbers. As an additional note, Gracelets could be used with JSF.
Components – 1.0
Score context: Rating based on how easy it is to package UI functionality into components and share them across projects. Component-based frameworks score high, request-based frameworks do not.
JSF is a component-based framework so no surprises here.
Ajax – 0.5
Score context: Rating based on two things: 1) if Ajax functionality is baked in and 2) how well the framework produces and consumes JSON. Hard-coding an Ajax framework reduces the rating as I don’t believe this is a good thing. If Ajax framework is configurable, 1.0 is given vs. 0.5.
Plugins or Add-Ons – 1.0
Score context: Rating based on if they framework has a plugin architecture and how many plugins are available.
One of the main features in JSF is its extendability and no better way to demonstrate that is by the number of 3rd party component libraries such MyFaces (various extra tag libraries), PrimeFaces, OpenFaces and IceFaces. Many companies are also building their own custom components, validators and converters.
Scalability – 0.5
Score context: Rating based on how much the framework relies on session state for functionality. Frameworks that require the session by default score lower. Also, frameworks like Grails that use Groovy (which is slower than Java) received a lower rating.
There are ways to configure this somewhat in JSF such as recreating the views before restore or keeping components on the client but neither is a perfect solution.
Testing – 0.5
Score context: Rating based on how much support for testing the framework has built-in. Frameworks that rename elements, making it difficult to test with Selenium, score lower.
JSF has a good set of unit testing tools such as JSFUnit and JSF-test (info here and here on this project). Both are outside projects.
Another alternative is SeamTest.
I18n and i10n – 0.5
Score context: Rating based on the framework’s support for internationalization and localization. This includes referencing messages in template code, as well as Java code. For example, JSF doesn’t make it very easy to get your app’s ResourceBundle in Java.
One line of code to get Resource Bundle registered with the application:
Score context: Rating based on the framework’s support for both client and server-side validation. Frameworks that don’t have client-side support receive a 0.5.
Standard JSF 2 has a basic server-side validation model which can be easily extended and JSF 2 supports Bean Validation model out-of-the-box. Client-side validation based on Bean Validation will be available in RichFaces 4.
Multi-language support – 1.0
Score context: Rating based on whether you can write core elements (e.g. Controllers, etc.) in more than one language (for example, Groovy and Scala). Frameworks that support Java, Scala and Groovy receive 1.0, ones that support only 2 receive 0.5. I determined languages supported by googling for the framework + the language.
Quality of documentation – 0.5
Score context: Rating based on how good the documentation is. Tutorial-style documentation is preferred, reference-style is essential.
There is official JSF documentation in Java EE 6 reference documentation from Oracle and literally thousands tutorials, articles and blogs posts on JSF. Kito Mann’s JSFCentral provides a central resource for everything JSF related.
Books published – 1.0
Score context: The more books the better
There are a number of good JSF books available.
REST support – 0.0
Score context: Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well? Lastly, to get a 1.0 rating, the framework needs to have its own REST client support like Spring’s RestTemplate.
JSF 2.0 adds support for REST (bookmarkable URLs). JSF can produce JSON & XML by adding a custom resource producing necessary output.
Update from (Matthias Wessendorf)/@mwessendorf:
bookmarkable URLS! = REST. Real rest is (very) hard w/ JSF
Old, but good post on this topic.
Mobile / iPhone – 1.0
Scorer context: Rating based on whether the framework has mobile support.
This one somewhat surprised me. JSF doesn’t have anything special for mobile support. But I guess as long as components generate standard compliant HTML, mobile support is there.
Degree of risk – 1.0
Score context: This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications.
Although JSF is not perfect, being the standard technology in Java EE 6 (and 5), with very active community and vibrant components and extensions ecosystem should make it a safe choice.
This is was a tweet that I sent in regards to comparing Java Web Frameworks:
I think the comparison is fun to some degree, it prompted a few folks including myself to a reply. It’s definitely a great topic for a conference. Any time you see vs or comparison in a talk title, developers get excited. My 2 cents: pick 2-3 frameworks, try them for a week or two. Try to build some pages, see if it’s a good fit, covers most of your requirements, developers like it, productivity is good, and it has 3rd party components or extensions (or make it simple to build them in house).
It’s important to point out again that probably very few companies use standalone JSF. I think most projects use JSF with RichFaces, Seam, Spring, where they have a lot extra features and functionality available.
Leave a Reply