Java-EE: Cleaner and simpler alternatives to JSF [closed]

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

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.

Answer 5

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.