Do you plan for javascript being off?

问题:

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.

回答1:

You need to write server-side code in any case to handle the posts, whether they are from AJAX or not.

So why not code according to the DRY principle, and reuse the same logic for standard postbacks and AJAX requests?

回答2:

I think you should support that. In fact, if your site involves SEO and bot indexing your site and all that, you SHOULD support javascript off.

As a modern web designer, you should first develop your site to be able to support Javascript OFF. then slowly add on effects and Javascript enhancements.

Example would be like:

<a href="page.php?p=2">Continue</a>

Then upgrade to:

<a href="page.php?p=2" onclick="doajax();return false;">Continue</a>

So say if a Javascript user clicks on the link, the AJAX is done but the usual link is disabled. However if a Javascript-OFF user clicks on the link, the user is redirected to the correct page with the same content that would be displayed to the javascript user.

If you're doing postbacks, you can do the same way for both AJAX or not.

The term that you build the site with no Javascript first, then add on the Javascript and AJAX features is called "Progressive Enhancement".

回答3:

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.

回答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).

回答5:

Generally, no. But it also depends on the type of application. If you're doing a highly windowed ("rich") application then it doesn't necessarily make sense to allow for it. To put it another way: the effort of doing so might be significant where the use case is unlikely/uncommon.

If you're doing an app where you control the user's environment (eg company intranet) then you really don't need to.

If you're doing a "normal" Web site where Javascript is largely decorative then you might but really, a site working without Javascript is largely incidental. If it happens to work, great. If not, well that's life.

Lastly, if your userbase is really large then it might be worth it. GMail is a Javascript-heavy site yet it has a plain HTML version, probably because it has so many users that the 1-2% of the population who disable Javascript are significant enough to cater for.

回答6:

The question is, Are you ok with 5% of your users losing the functionality of whatever you are putting into JavaScript? (assuming whatever you are doing doesn't do graceful degradation/progressive enhancement etc...)

If you answer no, then spend the time. I do like the point of asking users to turn JavaScript on. At least then they are aware that they have an option to turn on whatever they are missing.

回答7:

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.

回答8:

We do, but we have to strictly follow 508 compliance (accessibility for handicapped people). JavaScript causes difficulty for people who must use "readers" (programs which read the page, because the person can't see), so we must have a no JavaScript option.

回答9:

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.

回答10:

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.

回答11:

When developing web pages, I always develop with the assumption that JS is disabled. With that being said, there are many enhancements that require JS, so it is important to let the user know by using the noscript tag.

<noscript>JavaScript is required to use the advanced features on this page, please enable JavaScript.</noscript>

回答12:

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.