• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Server generated JavaScript/HTML/CSS vs. native

 
Ranch Hand
Posts: 859
IBM DB2 Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 297
5
Android Firefox Browser Fedora
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 15385
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
> 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
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic