Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our 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.

  • Tetsuo

    “When something goes wrong, how hard is it to understand how to fix it?”

    With JSF, very hard!

  • http://chillenious.wordpress.com/ chillenious

    “That’s pretty much it. All of them do that in one way or another.”

    Yes, but the devil is in the details. In fact, it’s the details – how it is implemented, what the API looks like, etc – that is what really matters. The fact that a framework ticks off a bunch of goals that are shared with the goals of other frameworks, doesn’t mean it is equally good or useful.

  • Christian

    Client state on the server is really bad design and against the core principles of the web (aka REST). Those frameworks, like JSF, come from an ancient era.

  • http://twitter.com/padcom Matthias Hryniszak

    Personally I think that JSF is trying to solve the wrong problems all along. It is not the component nature of web applications that needs solving (and in doing so producing markup that’s hard to style and understand, let alone extend) but rather to provide proper backend for DHTML/Ajax applications.
    Trying to marry the 2 worlds into a statefull hybrid (where the actual medious _is_ stateless – as in the HTTP protocol) makes combining the application with other web participants a nightmare.

  • http://twitter.com/padcom Matthias Hryniszak

    JSF is based on MVC? Please… it’s like saying that black and white television is also “color” because shades of gray are. It’s been the biggest “ouch” in the whole text above.
    JSF with its binding and server-bound client state is more ASP.NET WebForms but worse, more complicated and generally requires more work to do simple stuff.

  • http://twitter.com/padcom Matthias Hryniszak

    I’d like to add one more thing to the “why” part of the text: nowadays there’s this general dislike of polyglot programming. We’re kind of OK with using DSLs like XML, property files and the like but far less eager to use core web technologies like html, css and javascript.
    Like it or not the browser is a viewer that uses all 3 domain specific languages to achieve what it does so what you can do is either learn yet another DSL (the facelets DSL in this case) to do the job or you can simply go through the effort of learning the core ones which will pay off in the next and next and next web application projects no matter what technology you’ll use (besides JSF of course)
    To my liking it is so unbearably sad that people dismiss the simple ideas and take a shot at frameworks like JSF. I wonder when the era will come with something else replacing JSF like WebServices being replaced with REST.

    PS. jQuery+REST? Man you really need to explain what you mean. REST ain’t Ajax, not by a long shot!

  • http://twitter.com/padcom Matthias Hryniszak

    I couldn’t agree more.

  • creil

    I agree with understanding html, css, and javascript, but I use frameworks to be productive based on project requirements and team skill sets and JSF is one them. I have a core understanding of html and css, but I am going to use facelets, velocity templates, etc. for templating. I can write javascript, but I am much more productive with using rich components from something like Primefaces, which under the covers uses the JQuery library. Not saying that I would choose JSF for everything though. In my current job, we use it for internal, rich (desktop like) web applications. For public facing sites, with potentially larger volumes of user, I would probably using Spring MVC.

  • Hellocutie47

    I was one of those people who were hesitant to use JSF not because JSF is bad, it was my laziness to learn new technology. I thought, I know struts and it solves my problems, why bother learning a new technology that will solve practically the same problem.
    Until I was introduced to ADF in my new company. It really rocks big time.
    With that experience, I was always looking forward back then, to the next releases of Glassfish and Netbeans. All I can say is that the latest release of Netbeans and Glassfish will really make you more productive. I suggest that you guys get out of your comfort zones and try Netbeans with glassfish and its more likely that will find it more comfortable and fun to work with.

  • http://twitter.com/padcom Matthias Hryniszak

    Knowing and being proficient in core browser technologies allowed me to create rich user interface with little effort and at the same time to remain server-side agnostic. Take a look at JavaScript RIA frameworks (for example ExtJS), Silverlight or Flex – they don’t tell you what backend you need.
    With JSF it’s quite adifferent story: you’re left with no other choice but to do it JSF style (which is horrible to begin with and painful to move forward).

  • Altuga

    Ed said : Everyday more component libs become available for it …

    I said : JSF way is just wrapping current jquery libs and serve them as a new JSF components ??

    In JSF you are not free, just look Apache Wicket or Play framework and feel the freedom.

  • Sohbet

    how i can have JSF ? http://www.sohbetbak.com/

  • http://twitter.com/antonarhipov Anton Arhipov

    Yeah, NetBeans does a good job on the JEE side. It has some major drawbacks for SE development though. The editor gets better every time but still not as good as eclipse or IntelliJ, and also refactoring support could do better.

    Meanwhile the biggest weakness of NB is the speed of compilation or any other task execution as Ant-based engine takes ages to start.

  • http://www.facebook.com/armen.arzumanyan.100 Armen Arzumanyan

    From comments I understand what nobody know JSF but like do comments about it. Do you know what alfresco developed with JSF?

  • http://www.facebook.com/armen.arzumanyan.100 Armen Arzumanyan

    A lot of web applications based on JSF and JSF2, now all web technologies going to be component control, but no one can be smart, power and flexible which is JSF2

  • http://www.facebook.com/armen.arzumanyan.100 Armen Arzumanyan

    For example you can see also ArmCMS which I pushed to github, it is developed with JSF2 and MongoDB http://armcms.wordpress.com/2013/02/14/armcms-first-release-is-pushed-to-github/ enjoy!

  • http://www.facebook.com/armen.arzumanyan.100 Armen Arzumanyan
  • qwerty

    design of jsf looks like spagetti, the jsf application itself looks like spagetti. only the tomato sauce is missing

  • qwerty

    are you drunk?