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.

Yahiya

Answer 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?

Neely

Cause my controllers / post handlers will have to be doing a lot of if checks... with ajax I can just use a different controller for each operation. – Yahiya

You haven't specified which web framework you are using, but not all of them force you to do "a lot of if checks" just to support both AJAX and normal postbacks easily. If your framework does, I'd consider using a better one. For example, Lift makes all this very easy. – Neely

Yeah, I know :D This would be a breeze in something like ASP.NET, but I'm not using a framework at all :) Its an app engine project, and I feed django is great, but it huge overkill for what I'm trying to do. – Yahiya

Answer 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".

Wistful

Absolutely, SEO is my top priority... what I'm looking at is the site being read-only for non JS users - no voting, commenting, etc. – Yahiya

yep then that shouldn't be a problem for you. Just implement support for read-only features like AJAX paging and so on. – Wistful

Answer 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.

Nabataean

I'll have a message, sure... but graceful degradation requires much more time and planning than not doing it. And like I said, I'm working nights on this, so I don't have too much time. – Yahiya

@Sudhir Jonathan: why are you using javascript in the first place? If you have functionality that doesn't have a basic http analogy, then it's correct usage. Otherwise, you should have done the site first, and added the javascript later. – Enchain

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

Archipelago

Answer 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.

Forbidding

Answer 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.

Dobbin

That shouldn't be too bad, actually. The site would become almost read-only, though. – Yahiya

The problem is that if javascript is used for common functionality, like navigation links, it hurts not only users with javascript disabled, but also web crawlers like google bot. You definitely don't want to leave them unable to crawl your site. – Enchain

Answer 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.

Sayce

Agreed. If you're doing anything interesting, you'll need javascript. Develop for the future, not the past. – Biosphere

Answer 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.

Dollydolman

I've seen more articles that suggest that there is a misconception that somehow handicapped people can't use JavaScript. JavaScript != inaccessible, in fact, in some cases, it can render a site MORE accessible. The key is to understand what the JavaScript is doing and how it might challenge a handicapped person. – Dobbin

The real key is to actually get a screen reader yourself and try it on your site. – Luckin

Our problems is that we are subject to government regulations, and they say what we can and can't have. Their standards are based on old readers etc. We don't have technology issues, we have policy issues. – Dollydolman

Answer 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.

Selfsuggestion

Answer 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.

Chicago

Answer 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>

Espadrille

Answer 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.

Gittle