Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.

Ed Burns on Why JSF is the Most Popular Framework

Jevgeni Kabanov: Java EE Productivity Report 2011 marked JSF as the most popular web framework (or standard). This has drawn quite a few negative comments, including Matt Raible quoted in the report and a few others in comments and in the follow-up post Reactions to the Java EE Productivity Report. Personally, I felt that the comments were too aggressive and I asked Ed Burns, the JSF spec lead, for his opinion. This guest post is written by him. He raises some very interesting questions and I’d really like to see a reasonable discussion about this.

I’ll start by calling out some of the comments on the initial posting of the productivity survey:

I wonder how many would choose JSF if it wasn’t a JCP standard. Bruno Borges

And to answer your question about who choose JSF because it’s good, I think for JSF 2.0 that’s a lot. JSF 2.0 is a very good and productive framework. Everyday more component libs become available for it, and unlike JSF 1.x they work great together! (I.e. PrimeFaces, OpenFaces, RichFaces, they all work with each other)Hank de Boer

Above all what I don’t get is why a couple bloggers feel the need to downplay JSF so much. Is this some kind of jealousy because JSF is one of the few single frameworks with a significant amount of users in the otherwise very fractioned web framework scene?Arjan

Web Frameworks have always provoked heated and opinionated discussions. It’s like the Emacs or vi debate of the early 2000s. The fact that we’re still having the debate in the 2010s is a testament to the role of human nature in IT.

I tried various different frameworks, and a couple of them were quite nice really. But the thing is, JSF is also really quite nice, especially JSF 2.0. The component sets available for it are really cool (I especially like PrimeFaces) and there are many interesting extensions like those offered by Seam. Don’t forget that developers participating in this survey all did so out of free will and most likely indeed the active developers who have a passion for development participated. If they for some reason had to use JSF but didn’t like it, I don’t think they would be giving JSF ‘points’ in a survey such as this.Arjan

In my role as the individual who has the fortune of leading the JSF spec team, the existence of this back and forth is really the best validation available for our work on JSF. It’s important to point out that similar dialogs exist in the comment threads on other sites as well.

Premise: All Web Frameworks Solve the Same Problem

Let’s put opinion aside and look at some technical aspects. I want to limit the discussion to focus on frameworks where the UI logic and state resides mostly on the server. This excludes frameworks such as GWT (and its Vaadin abstraction), JQuery+REST, Flex, and, of course, JavaFX. Even with those exclusions there is still a huge amount of variety, but let’s take a look at what they all have in common. You could call this MVC, but I find these terms are easier to understand.

Problem statement

LIFECYCLE
All of them provide a request processing lifecycle in one way or another.
BINDING
In all of them, the purpose of the request processing lifecycle is to map the request data into a UI that hooks up to some business logic.
UI Construction
In all of them, some part of the development story involves producing some static artifacts that reside on the server (Java Classes, XHTML Pages, Velocity Templates, JSPs). These artifacts are executed by the server to produce HTML that is sent to the browser.

That’s pretty much it. All of them do that in one way or another. Now, let’s take a look at each element and ask some questions about the requirements for each subsystem.

Premise: All Web Frameworks Solve the problem differently, and at different levels of completeness.

Technical considerations, for all the subsystems:

  • Is the sufficient tool support?
  • How hard is the build process?

Non-technical considerations, for all of the subsystems

  • How hard is it to learn? Does it subscribe to the “pay-as-you-go” complexity tax, or the “all-up-front” complexity tax? In other words, can you pretty much forget about it until you actually need to do something specific with it?
  • Does the technology scale well to large teams with diverse skill sets and different levels of proficiency?

LIFECYCLE

Technical considerations

  • Does the framework handle all aspects of what can happen in a web request/response lifecycle?
  • Does it handle typesafe conversion?
  • Does it handle per-field validation?
  • Does it allow for inspection of the progress of the lifecycle, and interruption if necessary?
  • Does it respond well to malicious requests?
  • Does it respond well to DoS attacks?
  • Does it consume a lot of time? A lot of memory?
  • Is it extensible, decoratable, or otherwise customizeable?
  • When something goes wrong, how hard is it to understand how to fix it?

BINDING

Technical considerations

  • How easy is it to modify the mapping between request data and business objects on the fly?
  • Are all the necessary cardinalities of mapping supported?
  • How loose is the coupling between the artifacts in the UI Construction subsystem and the business objects?
  • Can the bindings be checked for type safety at compile time? Assembly time? Run time?
  • When something goes wrong, how hard is it to understand how to fix it?

UI Construction

Technical considerations

  • How good is its I18N/L10N story? Its A11Y story?
  • How maleable are the artifacts that comprise the UI?
  • Do they require redeployment to modify them?
  • Can the artifacts be templated for modular reuse? Can they be treated as true black-box components, with properties, methods, and events?
  • When something goes wrong, how hard is it to understand how to fix it?
  • What skillset must one have in order to author good-looking UIs? Is the skillset transferrable to other frameworks/jobs/professions?
  • How hard is it to do abstraction by aggregating artifacts into a composite artifact?

Non-technical considerations

  • Is there a third party market for UI artifacts?
  • Is the market strong and healthy, with new products entering regularly?
  • Can the products in this market be combined together to make new products?

Conclusion

I challenge you to take each of the framework contenders and ask these questions about them. I assert that JSF has very strong answers to all of the questions. Can the same be said of Wicket, Grails? Play? Echo2? Tapestry? Stripes? etc.

There are certainly areas of improvement for JSF. For example:

  • Pre runtime type safety checks in BINDING
  • Better runtime performance in LIFECYCLE and BINDING
  • Better error understandability in LIFECYCLE

Because JSF is a standard, developers can be pretty sure that the framework will receive continued refinement and development. When you combine that with the solid technical and non-technical aspects, that’s pretty darn compelling.

Ed

Ed Burns is a senior Java engineer at Oracle. Ed has worked on a wide variety of client and server side Web technologies since 1994, including NCSA Mosaic, Mozilla, the Sun Java Plugin, Jakarta Tomcat and, most recently JavaServer Faces. At Oracle (Sun), Ed leads a team of web experts from across the industry in developing JavaServer™ Faces Technology through the Java Community Process and in open source. Ed is currently the co-spec lead for JSR 127, JavaServer Faces, a topic on which Ed recently co-authored a book for McGraw-Hill. Ed is an experienced international conference speaker, with consistently high attendance numbers and ratings at the JavaOne conference, JAOO, W-JAX, No Fluff Just Stuff, JA-SIG, The Ajax Experience, and JUGs and Linux User Groups.