Is it worth it to code different functionality for users with javascript disabled?

Question

I\'m currently building a project and I would like to make use of some simple javascript - I know some people have it disabled to prevent XSS and other things. Should I...

Answer 1

Consider your audience

"Degrade gracefully" is generally the best answer. But lots of sites now depend on JS - especially AJAX.

Consider your audience. If your site is aimed at extremely tech-savvy people, the chances of them not having javascript are small, and you can notify them to turn it on if necessary.

If your audience may access your site with mobile devices, don't assume they have JavaScript, and don't even assume they support CSS properly. Aim to degrade gracefully all the way down to bare HTML.

Answer 2

It is essential to at least test your website is functional when JavaScript is turned off.

As orip says, degrading gracefully is very important. It should be vital that your page both looks nice and functions when JavaScript is disabled.

Answer 3

I've learned a lot from my question: What's With Those Do-Not-Use Javascript People

Go with Ajax and Web 2.0. It's the way the web is going and it's wonderful. Isn't Stackoverflow great to be on? It's not quite as nice with your Javascript turned off.

Once you have your site ready, but before you let it go live, test it with Javascript off, and just add whatever you feel you need to make your site appear and function to them. You only need to add what you feel is essential.

Remember, except for visually impared people using screen readers, the others have chosen to turn javascript off. They can also choose to trust your site and turn javascript on for your site if they want to use all the functionality you have. It really is their choice.

Answer 4

As said before, it depends on your target audience.

If I'm part of it, you want to make sure that your site works (if not ideally) on my phone, and that it gives me reason to turn Javascript on when I surf there with it off. Nobody expects full functionality with Javascript disabled, and anybody who uses their phone to access websites expects some issues, but you need to at least provide teasers. For a web store, make sure customers can see at least some merchandise anyway, even if they can't buy without Javascript.

Answer 5

Everyone else has committed good comments, but there are a few other considerations to make.

Sometimes the javascript will be hosted on a different domain, and be prone to timeout.

Sometimes that domain may become inacessible, while your site remains accessible. Its not good to have your site completely stack itself in this scenario.

For this reason, "blocking" scripts ( ie: document write inline ) like that present in google's tracker, should be avoided, or at very least, should go as late in the page as possible so the page renders whether or not the domain is timing out requests or not.

If you happen to be serving JS from a broken/malicious server, by intent or by accident, one can halt page rendering simply by having a script that serves that javascript which just calls "sleep(forever)" once its sent all the headers.

Some People Use NoScript

Like the above problem, sometimes the clients environment may block certain script sources, be it the users choosing, or other reasons ( ie: browser security satisfactions, odd antivirus/anti-malware apps ). The most popular and controllable instance of this is NoScript, and I myself paranoidly block some of the popular tracking/advertising services with it ( some proxy servers will do this too ).

However, if a site is not well designed, the failing of one script to load still executes code that was dependant on that script being present, which yeilds errors and stops everything working.

My recommendation is :

1. Use Firebug
2. Use NoScript and block out everything --> See Site still works
3. Enable core site scripts that you cant' do without for anything --> See site still works and firebug doesn't whine.
4. Enable 3rd party stuff --> See site still works and firebug doesn't whine.

There are a lot of other complications that can crop up, but satisfying the above 2 should solve most of them. Just assume that, for whatever reason, one or more resources that comprise a page are viable to spontaneously disappear ( they do, all the time ), and you want the page to "survive" this problem as amicably as possible. For the problems that may persist for < 10 seconds, its not so bad, refresh the page and its fixed, but if its a problem that can occur, and severley hamper usability for an hour or more at a time.

In essence, instead of thinking "oh, theres the edge case users that don't have javascript", try thinking more a long the lines of "its really easy to have something go wrong, and have ALL of our users with broken javascript. Ouch! Lets try make it so we dont' really hose ourself when that does happen"

( I've seen IE updates get rolled out and hose javascript for that entire browser until the people whom wrote the scripts find a workaround. Losing all your IE customers is not a good thing )

:set sarcasm

:set ignoreSpelling

:set iq=76

Don't worry, its only a 5% Niché Market

Nobody cares about targeting Niché markets right? All those funny propeller heads running lynx in their geeky stupid linoox cpus, spending all their time on the intarwebs surfing because they have nothing better to do with their life or money? the crazy security paranoid nerds disabling javascript left and right because they don't like it?

Nobody wants them as your primary customer now do they? Niché markets. Pfft. Who cares!

:set nosarcasm

Answer 6

It helps me in my implementations to think about it as "progressive enhancement" rather than graceful degradation. Degradation often leads you to figure out how to make it work w/o js after it is implemented, instead of making a baseline and enhancing with js.