JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY? [closed]

Question

Recently my company has decided to rebuild an enterprise portal, which will be used by people across the globe to resister there product for extended warranty. They have come up with J2EE ( spring MVC ) and Oracle as technology stack for the Business layer, and have decided to use JSF (java server faces) to design the front-end stuff ( User Interface) I am, being Frontend Engineer, want appose JSF since it will give less control over the generated markup to me, also JSF will inject/generate unnecessary markup in to the page, which will act as unhealthy food for the browser. Also it will become difficult to achieve the Browser Compatibility, since I don’t have any control over the markup generated It is hard to apply correct CSS behavior. Also it not possible to use concept like fluid layout , table less layouts. All this will result in poor User Experience. My idea is developed UI with hand coded HTML then convert those .html files in to JSP’s and plug those JSP’s in Spring MVC architecture.

Having said all this, I need to present a proposal which will justify the replacement of JSF by HTML for UI layer, your inputs/thoughts and suggestions will valuable, please write back.

Also, I don’t believe XHTML as other option, it has to be HTML? Let me know what do you think and what makes you think that way?

Thanks, for stopping by. I do apologies if reading all this has taken a lot of your time.

Answer 1

What you are stating is true when you're using vintage JSF 1.0/1.1 API with "pure" JSF components. There was no builtin component with which you can represent a HTML <div> element (so that you can accomplish the general page layout on a semantic manner). Also, embedding "plain" HTML in a JSF page was a pain because it got rendered outside and before the JSF component tree. You have to put plain HTML in <f:verbatim> tags over all place. The purists and the unawareness are less or more forced to use <h:panelGrid> (which renders a <table>) to position the elements in the page.

Apart from that, during the early JSF ages, Netbeans shipped with a builtin visual JSF editor which enables you drag'n'drop and bind JSF components visually without the need to write any line of code. This obviously generates a lot of at first sight unnecessary and unmaintainable code and the pixel-precise positioning of the elements were "behind the scenes" achieved with a <h:panelGrid>. Those kind of JSF applications are in view of maintainability and web semanticity a complete disaster.

Most of the negative stories you'll hear about JSF with regard to front end development is related to this. Most of the JSF users/observers/ranters from then are currently still blindly focusing on this because of the bad experience they had and/or they think that JSF is nowadays still the same and/or they see the visual editor as part of JSF while it's "just" another (bad) tool. Also most of the ones who says "JSF sucks" are usually ones who started using it with a visual / drag'n'drop editor without having any solid background knowledge of what's happening under the hoods (especially Servlet API!).

Since JSF 1.2 (which is already over 4 years ago released btw), the <h:panelGroup> component got an extra attribute: layout="block" which will let it (finally) render a fullworthy HTML <div> element so that you can bring a more semantic layout using JSF components only. But it's not only that, JSF 1.2 also comes with an improved view handler which enables embedding plain HTML in line among other JSF components without hassling with <f:verbatim> tags. You could nicely put <div> elements around where you want without adding more verbosity.

Even though this was a major improvement, there were still two other major (however not directly UI related) problems with the standard JSF implementation: 1) state management among requests is hard without grabbing the session scope (think of preserving the same data in tables and dropdowns and the conditions of e.g. rendered attribute); 2) everything goes through POST and you can't nicely invoke JSFish actions through GET.

Since JSF 2.0, which is almost already 1 year old, those problems were covered with a new scope, the view scope, and a new set of components for GET actions. Plus, JSP is replaced by Facelets as default view technology. Facelets greatly eases templating and creating composite components without having to resort with raw Java code and/or custom components/renderers. Even though it's XHTML based, it can perfectly render a HTML5 valid respone with just <!DOCTYPE html>. The XHTML is just there because Facelets is under the hoods using a XML based tool to generate the (X)HTML output. The XHTML based templating does in no way imply that it can only emit XHTML/XML.

All with all, your markup concerns are a non-issue when you're using JSF 1.2 or newer and also XHTML (Facelets) shouldn't be an issue since it can perfectly render HTML5 valid markup.

Answer 2

JSF gives you lot of predefined, rich controls that offer functionality would have to implement manually otherwise. The price for it is giving up control to certain degree in how user interact with the application and about HTML generated. It can also stand in the way of integration with JS libraries.

Debugging and testing is considerably simpler with JSP and specially with Spring.

It really depends on feature set of your web site, skills in the implementation team (and support team), time to deliver constraints, etc.

I personally prefer simpler technologies that give more control to the developer (JSP with Spring MVC) just for the internal elegance of the framework but that is never deciding factor ....