What are the main disadvantages of Java Server Faces 2.0?

Question

Yesterday I saw a presentation on Java Server Faces 2.0 which looked truly impressive, even though I am currently a happy ASP.NET MVC / jQuery developer. What I liked most a

Answer 1

After 5 years of working with JSF, I think that I can add my 2 cents.

Two major JSF drawbacks:

1. Big learning curve. JSF is complex, that's just true.
2. Its component nature. Component-based framework tries to hide the true nature of the Web, which comes with a huge amount of complications and disasters (like not supporting GET in JSF within almost 5 years).
   IMHO hiding HTTP Request/Response from the developer is an enormous mistake. From my experience, every component-based framework adds abstraction to the Web development, and that abstraction results in unnecessary overhead and higher complexity.

And minor drawbacks that come to my mind:

1. By default ID of the object is composed of its parents' ids, for example form1:button1.
2. No easy way to comment-out incorrect page's fragment. Tag <ui:remove> needs syntactically correct content which is parsed anyway.
3. Low quality 3rd party components which e.g. don't check isRendered() inside processXxx() method before continuing.
4. Incorporating LESS & Sencha is hard.
5. Doesn't play well with REST.
6. Not so easy for UX designers, because ready-to-use components have their own CSS styles, that need to be overwritten.

Don't get me wrong. As a component framework JSF in version 2 is really good, but it's still component-based, and always will be...

Please take a look at the low popularity of Tapestry, Wicket and low enthusiasm of experienced JSF developers (what is even more meaningful). And for contrast, take a look at the success of Rails, Grails, Django, Play! Framework - they all are action-based and don't try to hide from the programmer true request/response and stateless nature of the web.

For me it's major JSF disadvantage. IMHO JSF can suits some type of applications (intranet, forms-intensive), but for real-life web application it's not a good way to go.

Hope it helps somebody with his/her choices that regards to front-end.

Answer 2

I'm not a Java Server Faces expert at all. But IMHO the main disadvantage is that it's server side. I'm tired of learning and using server side web presentation layer frameworks like ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks and ruby on rails frameworks. I said goodbye to all of them, and I said hello to Angularjs and TypeScript. My presentation layer runs on the browser. I doesn't matter if it is served by Windows IIS running php or ASP.NET, or if it is served by an Apache web server running on Linux. I just need to learn just one framework that works everywhere.

Just my two cents.

Answer 3

JSF has only one disadvantage: before starting "JSF" development you should clearly understand web development, core java and front-end architecture.

Nowadays "new" JavaScript frameworks just try to copy/paste "JSF" component-based model.

Answer 4

"JSF will output View-layer HTML and JavaScript that you cannot control or change without going into Controller code."

Actually JSF gives you the flexibility, you can either use standard/third-party components or create your own which you have full control over what is rendered. It is just one xhtml you need to create your custom components with JSF 2.0.

Answer 5

To me the biggest disadvantage of JSF 2.0 is the learning curve not only of JSF, but the component libraries that you have to use in order to get it to do useful work. Consider the staggering number of specifications and standards you have deal with to really be proficient:

• HTML in the various incarnations. Don't pretend you don't need to know it.
• HTTP -- when you can't figure out what is going on you have to open Firebug and see. For that you need to know this.
• CSS -- Like it or not. It isn't so bad really and there are some nice tools out there at least.
• XML -- JSF will probably the first place you use namespaces to this degree.
• Servlet Specification. Sooner or later you will get into calling methods in this package. Aside from that you have to know how your Facelets gets turned into XHTML or whatever.
• JSP (mostly so you know why you don't need it in JSF)
• JSTL (again, mostly to cope with legacy framework)
• Expression Language (EL) in its various forms.
• ECMAScript, JavaScript, or whatever else you want to call it.
• JSON -- you should know this even if you don't use it.
• AJAX. I would say JSF 2.0 does a decent job of hiding this from you but you still need to know what is going on.
• The DOM. And how a browser uses it. See ECMAScript.
• DOM Events -- a topic all by itself.
• Java Persistence Architecture (JPA) that is if you want your app to have any back end data base.
• Java itself.
• JSEE while you are at it.
• The Context Dependency Injection specification (CDI) and how it clashes with and is used with JSF 2.0
• JQuery -- I would like to see you get along without it.

Now, once you are done with that you can get on with the proprietary specifications, namely the component libraries and provider libraries you will pick up along the way:

• PrimeFaces (my component library of choice)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (my JPA Provider)
• Hibernate
• Weld

And don't forget the container! And all those configuration files:

• GlassFish (2, 3, etc)
• JBoss
• Tomcat

So -- THIS IS MAKING IT EASY? Sure, JSF 2.0 is "easy" as long as all you want to do is the most basic web pages with the simplest interactions.

Simply put, JSF 2.0 is the most complicated and cumbersome mishmash of glued together technologies as exists in the software universe today. And I can't think of anything I would rather use.

Answer 6

A few drawbacks that pop to mind:

1. JSF is a component-based framework. This has inherent restrictions that have to do with obeying the component-model.
2. AFAIK JSF supports only POST, so if you want a GET somewhere you have to do a plain servlet/JSP.
3. Most components try to provide abstractions over domains like relational databases and front-end JavaScript, and many time these abstractions are "leaky" and very hard to debug.
4. These abstractions might be a good starting point for a junior developer or someone not comfortable with a particular domain (e.g. front-end JavaScript), but are very hard to optimise for performance, since there are several layers involved, and most people that use them have little understanding of what is going on under the hood.
5. The templating mechanisms that are usually used with JSF have nothing to do with how web desigers work. The WYSIWYG editors for JSF are primitive and in any case, your designer will give you HTML/CSS that you'll have to spend ages converting.
6. Things like EL expressions are not statically checked and both the compiler and IDEs are not doing a good job at finding errors, so you'll end up with errors that you'll have to catch at run-time. This might be fine for dynamically typed language like Ruby or PHP, but if I have to withstand the sheer bloat of the Java ecosystem, I demand typing for my templates.

To sum up: The time you will save with JSF, from avoiding to write the JSP/servlet/bean boilerplate code, you'll spent it x10 to make it scale and do exactly what you want it to do.