Quote:
Originally Posted by VIPStephan
How do you know what people expect? I’d say the first thing that people expect is a website that’s not broken in terms of layout and functionality. If I don’t have JS for whatever reason and a site is not working therefore then this is what I don’t expect. I expect that I can sign in to a website, for example. I don’t expect that the page reloads partially only (AJAX) when signing in. I don’t care how the site works as long as it works.
|
As professional web developer, It's my job to know what web users want, so i do a lot of research on the matter. This includes reviewing analytics, article pursuing, conference attending, and more than my fair share of direct user contact.
Once upon i time, it was my express determination to support every visitor to the sites i built. I even went so far as to integrate a restful text-only (ascii, not css) view for the CMS i built for my last job. The point was for users in developing nations with miniscule bandwidth can read the info we published. Since one of the potential destination sites for the framework was the atlas of world hunger, this was a key consideration. Know your audience, ascii and lynx support is not always needed.
When css first came out, a lot of well-respected "experts" advised to continue working with html3 tables, since not all browser supported CSS at the time. Eventually, developers became confident that 98%+ support was "enough" to remove unskinned views from the design iteration cycle.
Another factor is cost. Despite some number thrown around about development, there are other costs associated with good javascript-less sites. Server-side scripting requires a host, which requires public registration, and usually credit-card payment for the plan. Those things are way out of reach for the meager among us. Scott McNealy said that "Half the world dies without making a phone call".
Also, Lots of folks don't know server-side languages, and the penatly for back-end mistakes is MUCH higher than it is for annoying client-side script errors. Some people's hosting plans don't have server support; many hosted CMSs don't allow regular schmucks the ability to execute, other than pre-designed plugins. So, the only way for those folks to make a highly usable site is with javascript. Don't assume we can all run php.
I actually agree with the Luddites here that there is little point to having javascript on a brochure-like informational site, other than for the bells and whistles i previously alluded to. But, pages aren't always documents anymore; increasingly they are apps. If you just build brochures, stick with document-central languages like html and css.
But, if you are like the increasing number of developers creating HTML5 applications, i don't see a static fallback as possible or frankly, even desirable. Imagine google docs or maps without javascript...
i don't think that VIPStephan is "wrong" about javascript reliance; the old way is undoubtedly 1% more reliable than the new for reaching users. It's a battlefield-tested way of getting content to the seething masses. But, if you want to travel beyond the document and into app land, you won't get very far without client processing, be it javascript, flash, or something else.