JSF components libs generate awful html-code. It's not OK but is it acceptable?

Question

When I was developing web-apps with jsp/jstl and jQuery, I used to write nice html-code, separated from styles and scripts. JSP inserted some odd spaces and blank lines but nothing else.

Now I'm trying to develop with jsf. JSF has lots of libs for creating RIA with numerous components so it should be much faster to develop web-apps with jsf and some components library.

But all libs I've already tried generate awful html mixed with scripts mixed with some additional hidden inputs and styling inside html. These libs also often offer table layout (with different Panel, GridPanel and other components).

For me it looks terrible and I can't watch such a big mess in my html.

I don't know exactly but I think that ASP.NET generates something similar.

So, the question: is it a new standard of web-development - creating fast and dirty html?

Terris

Answer 1

JSP inserted some odd spaces and blank lines but nothing else.

That whitespace is by the way trimmable. In Tomcat and clones all you need to do is to set the JspServlet's init parameter trimSpaces to true.

But all libs I've already tried generate awful html mixed with scripts mixed with some additional hidden inputs and styling inside html. These libs also often offer table layout (with different Panel, GridPanel and other components).

If this is your major concern, then just go ahead with the basic JSF implementation. It provides everything you need to start with, if necessary with a little help of Tomahawk for more enhanced components (e.g. tableless radios/checkboxes) and the missing components (e.g. file upload and data list).

This way you can just do the CSS the usual way: completely externalized in a separate file and only using styleClass in JSF. Do not mingle inline CSS using the style attribute. If you want to stylize colonseparated JSF client ID's (colon is an illegal identifier in CSS), then you only need to escape it in the selector using a backslash. E.g. #formid\:inputid { background: gray; }.

Also do not mingle inline scripts using the on* attribtues. Use jQuery to introduce unobtrusive Javascript. As to the autogenerated Javascripts coming from JSF components, in the basic implementation you will only get this in h:commandLink which is basically an <a> element which submits a hidden POST form. As this is semantically/technically/SEO-ically wrong, I wouldn't use it at all. Just use h:commandButton to submit forms and h:outputLink to navigate.

As to table designs, since JSF 1.2 you can just write plain HTML in template. You can just use <div> elements to define positioned content elements. If you're a purist, you can even use JSF's <h:panelGroup layout="block"> to get a HTML <div> element. There is absolutely no need to use <h:panelGrid> to position content elements.

I don't know exactly but I think that ASP.NET generates something similar.

It does.

So, the question: is it a new standard of web-development - creating fast and dirty html?

No, you've it in your hands.

Despite

Thanks for 'trimStaces' and '\:', I didn't know about it. – Terris

Maybe because you misspelled it ;) Glad to bring new knowledge, you're welcome. – Despite

Answer 2

JSF implementations tend to produce valid markup. So it's not "dirty html". The fact that is is not easily human-readable is not important, so to answer your question - the generated code is acceptable.

Yesterday I performed PageSpeed and YSlow test on my MyFaces/RichFaces application, and apart from the inability to combine multiple CSS and JS files into one (reducing the number of http requests), everything else is fine.

Soprano

Yes, it's valid. You said very accurate - it's not human-readable. And nobody thinks about client-performance, clear DOM-tree and other old good practices. – Terris

Answer 3

I agree with you, the generated HTML by JSF (and all components libraries) is quite awful, but it is still valid.

I think the main problem is that the generated code must be compliant with the main browsers on the market, which include Internet Explorer 6+, Firefox, Opera, Chrome... This leads the developers to create sometimes a quite bad HTML just because "it works on every browsers"...

Smuts