JSF vs HTML(JSP) for enterprise portals UI layer. Which one to Choose? and WHY? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 10 years ago.

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.

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.

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

I did a stint as a UI Engineer for Barclays, a global bank. Now, I'll be the first to say that the financial industry has a long way to go when it comes to User Interface anything, and Barclays in particular is behind on their technology. That being said, they do know how to build things that effectively and reliably work, and the UI Lead is one of the most amazing minds I've ever had the opportunity to work with. Also, being a bank they are sticklers for compliance.

We were using exactly the alternative you proposed, and it worked well for us. Sites reliably handled millions of users daily with no negative outcomes. UI work was simple, and as a bonus when the Federal Card act came along, the company could hire basic web folks to come in and do the cutup/html work which engineers could then bolt into the system.

As for your XHTML question, ultimately we chose to go HTML 4.01 strict, and here's why: First, w3 has decided not to advance the XHTML working group...in essence, it's on its way to a slow death. Secondly, 4.01 strict is the closest to the HTML5 standard, and can fairly easily be adapted once 5 support becomes more widespread. A hard requirement for us was full compatibility on IE6, and this allowed us to achieve that goal.

In your negotiations, I would personally argue that it's vital that the final product meet current web standards (W3) because that makes it most possible to achieve a site that is compatible with browsers out there (I say most possible because I'm convinced that Microsoft with find a way, somehow, to break everything that I build eventually...it's how they roll) Secondary for your site might be SEO concerns with non-compliant code, and hindrances to accessibility such as screen reader support. You might also try outputting two similar (simple) sites using either technology and do an analysis of performance. In the case of one website I worked on that was served 1 million times per day, a 5k file size savings translated to 5gb of data daily.

Good luck! This is just one of many reason I got away from big corporate jobs using Java and Oracle....

I think jQuery based components coupled with an action based framework are the way to go. You get complete control over the page, very few surprises, fast development, and ultimately faster page performance. I've built apps with both JSF, and MS ASPX + DevExpress components. In the end I just want more control over what ends up on my page. jQuery is HUGELY popular, so there is no lack of JS talent in the market. Ajax is almost a no-brainer with jQuery too.

Also, for building database driven wep apps in Java nothing beats the speed of the Tagger Cat framework. It may be old school MVC, but it is seriously database focused, and nice to work with.