First of all, I don't really think people have any greater motivation "to upgrade Windows/Mac versions": Here are the usage share of web client operating systems (August 2010): Windows XP (48.32%), Windows 7 (19.81%), Windows Vista (18.43%), Mac OS X (6.42%), iOS (iPhone) (1.40%), Linux (1.34%). So nearly 50% are using an outdated OS (XP).
By contrast, here are the usage share statistics for browsers: Overall- IE (31.1 %), FF (45.1%), Chrome (17.3%), Safari (3.7%), Opera (2.2%). Breaking down IE by version- IE9 (0.2%), IE8 (17.3%), IE 7 (8.0 %), IE6 (5.6%). And for Firefox- FF4 (0.8%), FF3.6 (35.3%), FF3.5 (5.6%), FF3.0 (2.9%). So over 50% use the latest stable (or beta) versions of these browsers.
As for your other question--"How can you tell your end users that they will need to upgrade their browser to use the latest version of your website without a huge outcry?"--you must understand (i) the factors motivating people to upgrade, and (ii) the factors inhibiting people from upgrading; then you must use these factors to bolster your appeal to your end-users.
Motivators
What rewards do end-users get by upgrading? Skimming Microsoft's IE8 marketing materials, these are the motivators they stressed most:
- Appeals to Efficiency/Laziness:
- Faster surfing (i.e., you will gain more free-time if you switch)
- You can accomplish more work with fewer clicks, because of a more intuitive design. IE7 had put certain buttons in strange places, etc. (I.e., you will lose less effort [as measured in clicks] if you upgrade).
- Appeals to Security/Fear:
- SmartScreen protects you from malicious software (i.e., you will lose safety if you don't upgrade).
- Compatibility View allows you to view older pages correctly just as the website’s designers intended (i.e., you won't lose anything if you upgrade).
So motivators boil down to what the end-user will gain by upgrading (or lose if they don't upgrade). These things must be important to the end-user: Time, effort, financial security, compatibility, etc.
Reinforcers
Reinforcers aren't rewards, but they help increase the rate of adopting the desired behavior. Here's an example: Your web site can detect old versions of browsers, and direct users to download and install the latest versions by providing links and motivators.
Inhibitors
- Nuisance (cost in terms of time and effort) to upgrade
- Nuisance of learning something new
- New versions are inevitably buggy and suffer from incompatibilities that haven't yet been discovered
You must anticipate these arguments, and develop effective counter-arguments:
- There is a risk/reward trade-off, and the rewards outweigh these risks.
- New versions of browsers are fully supported, and bugs will be worked out. By contrast, older versions aren't well supported; and the oldest version have lost support entirely.
I use NoScript but whitelist any site I actually intend to use.
When you install NoScript, JavaScript, Java, Flash Silverlight and possibly other executable contents are blocked by default. You will be able to allow JavaScript/Java/... execution... selectively, on the sites you trust. You can allow a site to run scripts temporarily, if you're just surfing randomly, or permanently, when you visit it often and you really trust it. This means that NoScript learns from your own browser habits and tends to disappear in the background after a while, but it promptly comes back to save your day if you stumble upon a malicious web page.
When you browse a site containing blocked scripts a notification, similar to those issued by popup blocker, is shown.
Look at it or at the statusbar icon to know current NoScript permissions...
Best Answer
One disables JavaScript in a browser environment because of the following considerations:
Speed & Bandwidth
A lot of applications use way too much JavaScript for their own good... Do you need parts of your interface to be refreshed by AJAX calls all the time? Maybe your interface feels great and fast when used with a broadband connection, but when you have to downgrade to slower connection speeds, a more streamlined interface is preferred. And switching off JavaScript is a good way of preventing dumb-struck web-apps of refreshing the world every 15 seconds or so for no good reason. (Ever looked at the amount of data Facebook sends through? It's scary. It's not only a JS-related issue though, but it's part of it).
We also tend to off-load more and more of the processing to the client, and if you use minimalistic (or just outdated) hardware, it's painfully slow.
Usability & Accessibility
Not all user interfaces should expressed in a dynamic fashion, and server-generated content might be perfectly acceptable in many cases. Plus, some people simply don't want this type of interfaces. You cannot please everybody, but sometimes you have the chance to and the duty to satisfy all your users alike.
Finally, some users have disabilities, and thou shalt not ignore them, ever!!!
The worst-case scenarios here, in my opinion, are government websites that try to "modernize" their UIs to appear more friendly to the public, but end up leaving behind a big chunk of their intended audience. Similarly, it's a pity when a university student cannot access his course's content: because he/she is blind and his screen-reader doesn't support the site, or because the site is so heavy and requires ad-hoc modern plug-ins that he/she doesn't get to install on that refurbished laptop bought on e-bay 2 years ago, or again because he/she goes back home to another country for the spring break and the local bandwidth constraints cannot cope with the payload of the site.
Not everybody lives in a perfect world.
Platform Support
This point relates to the 2 previous ones and tends to be less relevant nowadays, as browsers embed JavaScript engines that are a level of magnitude more efficient than they used to be, and this keeps getting better.
However, there's no guarantee that all your users have the privilege of using modern browsers (either because of corporate constraints - which force us to support antediluvian browsers for no good reason, really - or other reasons which may or may not be valid). As mentioned by "Matthieu M." in the comments, you need to remember that a lot of people still use lower-quality hardware, and that not everybody uses the latest and coolest smartphone. As of today, there are still a significant portion of people using phones that have embedded browsers with limited support.
But, as I mentioned, things do get better in this area. But then you still need to remember the previous points about bandwidth limitations if you keep polling very regularly (or your users will enjoy a nice phone bill).
It's all very inter-related.
Security
While obviously you could think that nothing particularly dangerous can be done with JavaScript considering it runs in a browser environment, this is totally untrue.
You do realize that when you visit P.SE and SO you are automatically logged in if you were logged on any other network, right? There's some JS in there. That bit is still harmless though, but it uses some concepts that can be exploited by some malevolent sites. It is completely possible for a website to use JavaScript to gather information about some things you do (or did) during your browsing session (or the past ones if you don't clear your session data every time you exit your browser or run the now common incognito/private browsing modes extensively) and then just upload them to a server.
Recent vulnerabilities (working in major browsers at the time) included the ability to gather your saved input forms data (by trying out combinations for you on a malevolent page and recording the suggested texts for each possible starting letter combinations, possibly telling attackers who you are, where you work and live) or to extract your browsing history and habits (A very clever hack doing something as simple as injecting links into the page's DOM to match the color of the link and see if it's been visited. You just need to do this on a big enough table of known domain names. And your browser getting faster at processing JavaScript, this type of thing gets done quickly.)
Plus let's not forget that if your browser's security model is flawed, or the websites you visit don't protect themselves when enough against XSS attacks, then one might use JavaScript to simply tap into your open sessions on remote websites.
JavaScript is mostly harmless... if you use it for trusted websites. Gmail. Facebook (maybe... and not even...). Google Reader. StackExchange.
But yeah sure, JavaScript cannot be that bad, right? And there are scarier things to fear online anyway. Like thinking you're anonymous when you really aren't that much, as shown by the Panopticlick experiment of the EFF. Which is also partly done using JavaScript. You can even read their reasons to disable JavaScript to avoid browser fingerprinting.
All this being said, there might be perfectly good situations where you don't need to bother about supporting JavaScript. But if you offer a public-service website, do consider accepting both types of clients. Personally, I do think a lot of modern web-apps and websites would work just as well using the former server-generated content model with no JavaScript at all on the client side, and it would still be great and possibly a lot less consuming.
Your mileage may vary depending on your project.