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.
