What are the main disadvantages of Java Server Fac

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 about JSF was the huge amount of AJAX-Enabled UI components which seem to make development much faster than with ASP.NET MVC, especially on AJAX-heavy sites. Integration testing looked very nice too.

Since the presentation only emphasized the advantages of JSF, I'd like to hear about the other side as well.

So my questions are:

• What are the main disadvantages of Java Server Faces 2.0?
• What might make a JSF developer consider using ASP.NET MVC instead of JSF?

Answer 1

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 2

1. Inexperienced developers usually will create applications that are painfully slow and code will be really ugly and hard to maintain. Its deceptively simple to start, but actually requires some investment in learning if you want to write good programs.
2. At least at the start you will often "stuck" on some problem and will spend more time reading balusc posts on internet than actually working :) After a while it will be less and less of that, but it still can be annoying.
3. Even more annoying when you find out that the problem is not due to you lack of knowledge/mistake but actually a bug. Mojarra was(is?) quite buggy, and another layer of components adds even more problems. Richfaces was biggest piece of crap software ever written :) Don't know how it is now on version 4. We have Primefaces which is better, but still you will run into bugs or lack of features especially with more exotic components. And now you will need to pay for Primefaces updates. So I would say its buggy but its getting better especially after 2.2 version fixed some problems with spec. Framework getting more mature but still far from perfect (maybe myfaces better?).
4. I don't find it especially flexible. Often if you need something very very customized and there are no components that does that - it will be a bit painful. Again I'm talking from average developer perspective - the one with deadlines, quick reading tutorials, and searching stackoverflow when getting stuck because no time to learn how it really works :) Often some components seems to have "almost" what you need, but not exactly and sometimes you might spend too much time to make it do something you want :) Need to be careful in evaluating if its better to create your own or torture existing component. Actually if you are creating something really unique I would not recommend JSF.

So in short my drawbacks would be: Complexity, Not very smooth development progress, buggy, inflexible.

Of course there are advantages too, but that's not what you asked. Anyway that's my experience with framework others might have different opinions, so best way is to just try it for a while to see if its for you (just something more complex - not naive examples - JSF really shines there:) IMHO best use case for JSF is business applications, like CRMs etc...

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

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 5

For me the biggest shortcoming of JSF is poor support for programmatically (dynamically) generated pages.
If you want to construct your page (create page component model) dynamically from java code. For example if you are working on WYSIWYG web page constructor. Adequate documentation of this use case in not generally available. There are many points where you have to experiment and development is quiet slow. Many things just don't work how you would expect. But generally its possible hack it somehow.
Good thing is that it's not problem in philosophy or architecture of JSF. It's simply not elaborated enough (as far as I know).

JSF 2 brought Composite Components which should make component development easy, but their support for dynamic (programmatic) construction is very poor. If you overcome quiet complicated and almost undocumented process of dynamic Composite Component construction, you will find out that If you nest few Composite components little deeper, they stop working, throwing some exceptions.

But It seems that JSF community is aware of this shortcomings. They are working on this as you can see from these two bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

Situation should be better with JSF 2.2 at least if we are talking about specification.

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.