Do you plan for javascript being off?

Question

I'm coding a fairly large and complex site by myself, so do you think I need to support javascript being turned off?

Its a lot of extra work supporting full page postbacks for stuff I could quickly do with JSON and ajax.

Answer 1

A lot of traditionalists will tell you to code for javascript off browser. My opinion, as you stated, it is far too expensive for most organizations to do. However, you should check if JS is on, and if it is off, redirect the browser to a page specifying the requirements for using the system.

Answer 2

You should fail gracefully if JavaScript is turned off.

As a bare minimum you should put up a message along the lines of "You must have JavaScript enabled to use this site" - however, depending on your site, that could be cutting off a large proportion of your potential audience.

You might want to consider something somewhere in between this and fully duplicating your functionality with postbacks.

Answer 3

Like others have said, it depends.

There are three traditional use cases where disabled javascript was "expected":

• mobile
• people with disabilities
• high-security environments.

All of these are evolving to include javascript in the normal usage scenario:

• Mobile browsers are gaining advanced javascript support
• The web accessibility standards are currently being overhauled to support javascript-driven web sites.
• Browsers like google chrome demonstrate that javascript engines can be effectively sandboxed.

So, the long term trend is that for all cases you are going to be expected as a user to have javascript enabled. The question regarding what you do today is based on your target audience and what they're using right now. This you should know.

Progressive rendering ... that's a different topic. Gmail doesn't do progressive rendering, it just has a separate front-end for people who can't use the full front-end. That separate front-end doesn't do everything the full gmail does. Myself I make web apps, and I tried progressive rendering for a while, but ended up using gmail's model in the end:

• Rich front-end, requires modern browsers with javascript and styling enabled. If the browser is not capable enough, it falls back to ...
• Simple front-end, basic html, basic featureset, targetted towards mobile devices, but usable for people with disabilities also

This model allows me to deliver a better user experience for all my users, at a lower cost than when using progressive rendering. YMMV.

Answer 4

It depends

I generally work first on an AJAXless site and build up.

Always try to be trustful to the concept of graceful degradation and unobstrusive javascript.

• Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation
• Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)
• Progressive enhancement to support user agents that may not support advanced JavaScript functionality

This can be achieved by making sure links and forms can be resolved properly and rely not solely on Ajax. In JavaScript, e.g. a form submission can be halted by using "return false". If nothing goes wrong, Ajax code will be executed and the form submission will be skipped. If any problems occur with the user agent’s Ajax support or if the user does not have JavaScript enabled, the form will be submitted and the traditional version of the action will be performed.

On some sites it could be more work than it's worth, but generally people use AJAX for coolness sake, that it's always a bad reason, and end up giving up with pages that break http common and basic functionality (like bookmarks and open in new tab when clicking).

Answer 5

Always plan for JS disabled - however, know the user base. Most js-disabled people don't browse with desktop browsers, they browse with some crappy mobile phone browser with a viewport the size of a penny. Or something similar. Make a dead-simple, bare bones design for this crowd if you feel the need to include them. Some do; some don't. It's simply a question of what your product/user base is.

Second, an ajaxified form with a no-js fallback is truly simple: design the form to work as a regular post form, then make an ajax call that gathers all the info it needs from the form. This includes, but is not limited to, field data, post url, method, name, etc. If you have js UI pieces that change depending on the user's decisions in the form (checkboxes, radio boxes, etc), you can use jQuery to check the hidden checkbox (that would be displayed in the no-js form) and base all of your events off the checkbox click (item.click()) rather than the fancy js UI element's click. This way, your form will accurately reflect the state of the application at all times, and your no-js and js implementations are completely in sync.

Answer 6

It depends on which audience you're application targets. Building a site initially with javascript functionality without regard of whether the users have it or not is bad practice in my opinion. But everyone designs/develops sites the way they want. I like to first code a site without ANY javascript what so ever. Make sure it works, then progressively enhance it with javascript.

Sure it's a lot of work to make your site accessible. If your application targets the gaming community I wouldn't worry about accessibility too much. If your application is subject to government regulations then following WCAG and Section 508 is a requirement.

The benefit of following WCAG and Section 508 is that you kill 2 birds with one stone. Not only is your site accessible to humans with limited mobility, but its also accessible to screen readers and search engine spiders.