25

We are starting to develop a web application using Java EE 6.

We got surprised with the complexity of the JSF's generated HTML. I mean even a simple link has some javascript handling code. and this is, in my opinion, a usability problem because browser's gestures (as "ctrl+click" over a link) simply doesn't work. Also, I'm suspecting this could get worse when we need to maintain that code or tweak the UI design with javascript frameworks like jQuery. it reassembles me: Webforms vs ASP.Net MVC. complexity against simplicity.

Anyway this is my first time with JSF. so I really would like to read your experiences with it.

Do you know a simpler rendering engine for Java EE?

How has your development experience with JSF been?

Have you developed a web app using JSF and lots of jQuery/Dojo/Script.aculo.us?

Community
  • 1
  • 1
SDReyes
  • 9,798
  • 16
  • 53
  • 92
  • 4
    You may wanna look into the lighter frames available, like Apache Wicket and the like. I personally find JSF way too heavy & scripted for most applications, except for when you don't care THAT much about the validity of the generated code etc. and just need to get things done in a really short time... – TC1 Jun 10 '11 at 13:51
  • Perhaps this should be migrated to programmers.stackexchange.com? – maple_shaft Jun 10 '11 at 15:32
  • 2
    Related: http://stackoverflow.com/questions/3623911/what-are-the-main-disadvantages-of-java-server-faces-2-0 – BalusC Jun 11 '11 at 16:10

5 Answers5

22

It is hard to define what "simple" means when you ask about a "simpler rendering engine". JSF is a very unique animal and I am afraid there isn't anything simpler that is also similar in the Java world.

My experience with JSF has been EXTREMELY positive, and this is coming from someone with years of experience developing under ASP.NET. The learning curve is still steep, and I can't imagine complex enterprise systems being possible without some form of custom Javascript and possibly even custom components, however in my opinion it is simpler than ASP.NET and much less heavy as well. They addressed a lot of the issues that made ASP.NET so difficult to work with, (Eg. simple client ids for the DOM, XHTML compliance).

I recently developed an application that will be going to production shortly using only Primefaces components, standard Mojarra facelets, one custom component, and a handful of Javascript/hidden input field workarounds for component framework bugs. It was stunningly easy aside from the few workarounds I needed to implement. I am extremely happy with the results, the stakeholders LOVE IT and I will absolutely use it again in my next project.

In formulating a team my real world experiences with it tell me that it is best to put a highly experienced web application developer as a lead on the project, someone with superb experience in Javascript, CSS and Java web technologies. The rest of team could be entry level developers with a modicum of guidance.

maple_shaft
  • 10,435
  • 6
  • 46
  • 74
  • Thank you for your team building recommendations :). How did you manage to fix components' bugs using javascript? did you extend the component or something like? +1 – SDReyes Jun 10 '11 at 16:21
  • The only composite component I created was to remove unwanted stylesheet themes from certain Primefaces form components and to be honest I ripped that code off from user healeyb on the Primefaces forum! http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=7882&sid=200916f06788680fe55bbdb6c5c30b33&start=10 (cont...) – maple_shaft Jun 10 '11 at 16:27
  • An example of a javascript workaround would be, a bug in the Primefaces dataTable where ajax calls from within the dataTable don't refresh the contents of the dataTable asynchronously on the client. I had a Delete button in a column to delete a single row. What I did was created a regular HTML button that invoked a custom JS that took the ID of the DOM row element and set that as the value of a hidden input. I then invoked a click event on a hidden Primefaces button that was outside the dataTable to asynchronously post back and delete the row item that matched the ID in the hidden input. – maple_shaft Jun 10 '11 at 16:31
19

I've been working with JSF on a large project. I have experience of working with JQuery, normal HTML/css/javascript, GWT and Gxt. And I can tell you that JSF is the worst of the bunch. If you like your back-end code to be separate and independent of your front-end code then JSP is not the way to go. It littery ties your front-end to your back-end with no clear separation of concerns. The other problem with JSF is that it is very hard to get your head around. Creating great AJAX pages in using frontend technology (e.g. javascript, html and css) is very easy. My 14 year of son gets taught how to do it at school. Getting the same effect using JSF is incredibly complicated. Take a look at how to define as link: <h:commandLink value="New" immediate="true" action="#{projectUiService.showProjectCreate}" />. And there is no way to specify a form action url. You have to use the JSF managed beans and navigation semantics. It's a completely new front-end language. So even if you want to style up the front-end or add JQuery in you'll be stuffed.

Configuring your build and runtime environment is also a pain. There are so many inter-dependencies among jar files that if you don't have the right combination of JSF, Richfaces, and Spring Jars, then you have no hope of getting your application even out of the build build environment. If you want to get a hint at this then go to the maven search site and look for the class javax.faces.component.UIViewRoot. Everyone and their dog has it. Also take note at the javax.faces and com.sun.faces - what's the difference? Who knows, but they don't work together. And some version only work with specific version of RichFaces.

My advice - stay well clear. Give your app a spring back-end and a normal HTML front-end. There is no way you can write a decent large enterprise scale application in JSF. It would be just too complicated. You'll end up with a huge monolithic code base that would be almost impossible to maintain.

Adam Davies
  • 2,742
  • 4
  • 33
  • 52
  • 11
    20+ years programming and web-dev since 1995 ... JSF 1, and now 2 are a step backward IMHO from the web 2.0 ideas. The worst part is the monolithic layer joining such that only a Java developer can participate in the project (XHTML cannot be styled natively - it has to be rendered in a container and there are no guarantees about the result depending on the exact version, etc). So no HTML developer doing the mock-up, someone with CSS/3 and JS skills to make it look good. Instead you get the defacto controls from Rich/Prime with minimal control/style options - the result is frankly 'clunky'. – Darrell Teague May 18 '13 at 15:31
  • 3
    Agree. JSF is making simple things way too complicated... I usually mix the JSF tags and EL with javascript inside JSP... bad style maybe but easier to achieve my goal. – SwiftMango Jul 13 '13 at 09:35
  • yea i'd stay away from JSF and use spring as the backend and Vaadin (https://vaadin.com) as the frontend – FearlessHyena Sep 30 '14 at 21:38
  • @Adam JSF has an ability to redirect you to the page with the ManagedBean method return value or just by putting the page code in the `action` attribute. Also JSF is doing a lot of work for you - e.g. how are you going to validate the parameters you pass to the server? How are you going to bind the form fields to the enity? – iozee Oct 10 '14 at 09:57
7

Do you actually need a component-based framework like JSF or are you looking for a more traditional web request-based MVC framework? If so, you may want to look into Apache Struts2 or Spring MVC. Spring MVC requires that you use the core Spring library.

Steven Benitez
  • 10,936
  • 3
  • 39
  • 50
5


I've been working with JSF for 3 years and I can say that the most powerful thing about it is that it abstracts the communication between browser (form input or actions) http request and Java.
There are rich libraries available for JSF, like: ICEfaces, RichFaces, ADF Faces, PrimeFaces, which gives you a big amount of rich components that may be enough for you.
JSF tries to make development of web applications more close to desktop applications. It addresses the most common tasks for a web application (no matter the technology) and automates them using its LifeCycle.
However if you want in some cases a certain behaviour that's different from how a component works, you have to make some workarounds, or build your own components (which may be hard, except for composite components).
I have integrated JS successfully for tasks that didn't need to trigger some action in Java like select all checkboxes, hide/show some parts of the page, and so on.
JSF is very easy, yet very powerful, and requires a certain expertise for some tasks.
The last version of JSF, 2.0, addresses the common problems JSF had, because of its POST nature, so now I'm very happy with it.
Regarding users gestures like ctrl+click, the way web applications in JSF work is a little different than normal ones, buttons Back, Forward, Refresh might not work as expected sometimes. But hey, great web applications have the same behaviour: Try Ctrl+Click in PayPal .. or try Back Button in Vodafone.ro
If you want full control over your HTML, use plain JSP. But when you have a huge web application, JSF is a good option for Rapid Application Development(RAD).

Shahid Ghafoor
  • 2,991
  • 17
  • 68
  • 123
Cosmin Cosmin
  • 1,526
  • 1
  • 16
  • 34
  • Yeah. now, I think it's a good trade off to lose some gestures in favor of RAD. thank you Cosmin +1 – SDReyes Jun 11 '11 at 17:00
0

Do you know a simpler rendering engine for Java EE?

JSF IS the most powerful technology for presentation layer in the mainstream Java EE. That became true only after introduction of "Composite Components". However the less known HybridJava solution is non less powerful but yet simpler than JSF.

Dima
  • 1,326
  • 2
  • 13
  • 19