We're developing a web application that is going to be used by external clients on the internet. The browsers we're required to support are IE7+ and FF3+. One of our requirements is that we use AJAX wherever possible. Given this requirement I feel that we shouldn't have to cater for users without javascript enabled, however others in the team disagree.
My question is, if, in this day and age, we should be required to cater for users that don't have javascript enabled?
My question is, if, in this day and age, we should be required to cater for users that don't have javascript enabled?
Yes, definitely, if the AJAX functionality is core to the working of your site. If you don't, you are effectively denying users who don't have Javascript enabled access to your website, and although this is a rather small proportion (<5% I believe), it means that they won't be able to use your site at all, because the core functions are not available to them.
Of course if you're doing more trivial things with AJAX that just enhance the user experience but are not actually central to the core functionality of the site, then this probably isn't necessary.
Depends really.
I personally switch off JavaScript all the time because I don't trust lots of sites.
However, since you users have explicitly asked for your application, you can assume they will trust it and there is no point in doing extra work.
More, if you have that strong AJAX-affinity requirement, the question seems odd enough.
This question comes up a couple times per week here, and you have enough rep you should know that. Did you search?
Anyway, the thing here is that there are a lot more users on the public internet who may have trouble with javascript than you think:
Of course, you need to know your audience. You might be doing work for a corporate intranet where you know that everyone has javascript (though even here I'd argue that there's a growing trend where these sites are made available to teleworkers with unknown/unrestricted browsers), or you might be building an app for the blind community where no one has it. In the case of the public internet, you can typically figure that about 95% of your users will support it in some fashion (source cited by someone else in one of the links below). But that number isn't as high as it sounds. Turn it around, and if you don't support javascript you're turning away one visitor for every 20.
See these:
I think that depends on the type of web application you are going to build. For example in an e-commerce application the checkout process should propably work without java script because there are some people who deactivate js for checking out (in our experience). In a web 2.0 application in my opinion it isn't necessary to support non-js browser experience. Developing for both also complicates the development process and is more cost intensive. you have double your web test efforts (testing with and without js) and also think different in the planning phase.
I think it depends on the market segment you're aiming for, if you're going for a tech crowd -such as Stackoverflow.com, or perhaps slashdot- then you're probably fine in expecting users to have JS installed and active.
Other sites, with a medially tech-aware audience, may suffer from users knowing enough about JS-based exploits to have deactivated JS, but with not enough knowledge to enable Scriptblock (or other browser-equivalent).
The non-tech aware audience are probably with the tech-crowd, since they possibly just don't know how to disable JS -or why they may want to- regardless of the risk.
You should weigh the options and ask yourself:
1) what percentage of users will have javascript turned off. (according to this site, only 5% of the world has it turned off or not available.) 2) will those users be willing to turn it on 3) of those that aren't willing to turn it on, or switch to another browser or device that has javascript enabled, is the lost revenue more than the effort to build a separate non-javascript version?
Instinctively, I say most times the answer is no, don't waste the time building two sites.
In short, you should cater to spiders without JavaScript enabled, but only to the degree necessary to index the data that you want to expose to the public. Your browser requirements of IE7+ and FF3+ exclude far more people than the total number of people who disable JavaScript. And of those who do disable it, the vast majority know how to enable it when necessary.
I asked myself the same question the other day and came up with the answer that in order to use my application one must have Javascript enabled. I also checked various Ajax powered sites. Even Stackoverflow.
But considering this fact I also believe that you do need to support some degree of prehistoric applications. The main idea is to not let application break when users don't have enabled Javascript. Application should still display relevant data, but its functionality would be limited.
This is an issue that I was thinking about just a few days ago. Here is some information
These stats made me think. Do I have to break my back writing a lot of background code and everything for users who have disabled Javascript?
My conclusion was this. Yes, I have to include Javascript support, but not at the cost of sanity. I.e. I can afford to give it a low priority.
So I am going to have support for non-javascript browsing, but I will build most of it after my site is deployed.
This is a bit like beating a dead horse, but I'll have a go at it, sure.
I think there could be two basic approaches to this:
1.
Using ajax (and, basically, javascript) to enhance the experience of the users, while making sure, that all of the application's features work without javascript.
When I am following this principle, I develop the interface in two phases - first without considering javascript at all (say, using a framework, that doesn't know about javascript) and then augment certain workflows by adding ajax-y validation (don't like pure js validation, sorry) and so on.
This means, if the user has javascript disabled, your app shall in no way break or become unusable for him.
2.
Using javascript to its fullest, "no javascript - no go" style. If javascript is not available, the user will not be able to use your application at all. It is important to note, that, in my opinion, there is no middle ground, - if you are trying to be in both worlds at once, you are doing too much extra work. Removing the constraints of supporting no-javascript users, obviously adds more opportunities to create a richer user experience. And it makes creating that experience much easier.