aspose file tools*
The moose likes HTML, CSS and JavaScript and the fly likes Server generated JavaScript/HTML/CSS vs. native Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "Server generated JavaScript/HTML/CSS vs. native" Watch "Server generated JavaScript/HTML/CSS vs. native" New topic
Author

Server generated JavaScript/HTML/CSS vs. native

William P O'Sullivan
Ranch Hand

Joined: Mar 28, 2012
Posts: 860

Hello Rob, A topic dear to my heart.

So, What is your opinion (and anyone else) regarding frameworks such as JSF, zk, gwt rendering browser content ...

over ...

Front-end Developers having complete control via static .js,.css,.html etc.?

When I worked in eCommerce, it was a nightmare maintaining, tweaking and hacking each page to render properly.
The situation will only get worse as html5/css3 start maturing and browser suppliers (not vendors, since they don't charge)
lag behind in support.

IMHO, there should be, and partially are ways to detect browser versions etc. at the server level, but no way to determine
their support of these new features. Chrome has it's gallery as does IE to "prove" their support.

Why not a standard header/request parameter map that can tell our back-ends exactly what is and what is not supported?


WP
Rob Crowther
author
Ranch Hand

Joined: Nov 06, 2012
Posts: 269
    
    4

Hi William. Your post covers a lot of ground so I'm going to pick out some bits and comment on them in turn.

William P O'Sullivan wrote:So, What is your opinion (and anyone else) regarding frameworks such as JSF, zk, gwt rendering browser content ...

over ...

Front-end Developers having complete control via static .js,.css,.html etc.?


I've always been a markup monkey so I love having the direct control. I spend most of my working day coding in ASP.Net (Forms not MVC, so I'm dealing with a slightly outdated framework to start with) and while I was learning that I often found myself frustrated by the apparently random unnecessary wrapper elements and tables all the standard controls seemed to add, not to mention the insanely long IDs you end up with (and on almost every element!). However producing clean, minimal but working markup is a skill which takes practice like any other and a lot of developers who focus primarily on the server side don't have the time and/or the inclination to learn, plus the arguments for spending time on markup rather than plugging components together in a B2B environment are tenuous to start with (at least until there's a sudden business requirement to do something in markup outside what the framework supports). And then I've seen cases where developers have used a framework where they complete control and they're produced a bigger mess of tables within tables and IDs on everything than even ASP.Net Forms would produce. So I think on balance a framework which allows a developer not to worry about markup at all is a good thing, provided there is an easy to use mechanism within the framework that allows someone to worry about the markup.

William P O'Sullivan wrote:When I worked in eCommerce, it was a nightmare maintaining, tweaking and hacking each page to render properly.
The situation will only get worse as html5/css3 start maturing and browser suppliers (not vendors, since they don't charge)
lag behind in support.


I think you're wrong there. One of the reasons it took so long to get CSS2.1 from draft to W3C Recommendation is that web standards these days are required to have compatible experimental implementations before they can be approved. This is a change from the old process (for example CSS2) where the standard was published and only then were implementations attempted and all the practical problems with the spec discovered. All new W3C standards require the creation of a test suite before they can move to Recommendation status, so it will be possible to say definitively whether or not a particular browser implements the standard correctly based on whether or not they pass the tests. Poorly specified areas will be spotted much more quickly as a result, so implementations should be far more compatible than ever before.

In the case of the HTML5 spec an inordinate amount of time has been spent on specifying (and therefore standardizing) what browsers should do with invalid markup. Even when browsers don't support a particular tag they will fail to support it in a consistent and predictable way. The situation really can only get better in this regard.

William P O'Sullivan wrote:Why not a standard header/request parameter map that can tell our back-ends exactly what is and what is not supported?


I think the main problem with this idea is that the header would be huge, it could end up adding megabytes to every request. Have a look at all the standard tests for Modernizr, and that's just the popular stuff, there are additional libraries of user written detection scripts.


Read my books: Hello! HTML5 & CSS3 | HTML5 in Action | Read my blog
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
> Why not a standard header/request parameter map that can tell our back-ends exactly what is and what is not supported?

Do you know how large that object would be? Do you know how many settings and options there are in a browser? It is nearly impossible and would add gigs to a request, that is not efficient. The proper way to handle it is code that sniffs for object support and it should also die gracefully. Look at the HTML5 inputs. If number is not supported you get a textbox! Still useable and you can code your own JavaScript to add support if you really want to [and there are libraries that do it already]

> So, What is your opinion (and anyone else) regarding frameworks such as JSF, zk, gwt rendering browser content ..

My personal opinion on frameworks that spit out JavaScript:

You wrote a novel in English. You than decide you want to have a Spanish edition of your novel to hit a new market. You go to Google Translate and convert it to Spanish. You do not understand Spanish so you can not proof read it. You send it off to a publisher.
Your novel in Spanish is only as good as the tool that translated it. You just pray that the framework that does the translation did their job.

If you do not know JavaScript and the tool spits it out, you just hope that the developers that wrote the translation did their job and you hope they did it efficiently.

Eric
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Server generated JavaScript/HTML/CSS vs. native
 
Similar Threads
CSS with Struts-html tags.
How can I center html:errors in a table?
How to include HTML file in core java application
hibernate is backend technology or front end
CSS with Struts-html tags.