It’s the instinct of most programmers to reduce all sorts of code. The less code, the fewer complexities, and the fewer points of possible error in said code. This rule applies to Javascript just as well as other languages. You’re just upholding the tradition.

Use Javascript as needed/desired within HTML pages… but there’s no reason to use it when its not actually needed.

10 years ago, it might have been a good idea. Nowadays most parts of the internet (- at least some very popular parts -) have become almost unusable, or provide only a very restricted functionality, when disabling Javascript in the browser. So IMHO today you can expect your users to have Javascript enabled.

And there are lots of frameworks like JQuery to get around browser incompatibilities. IMHO there is no real reason today why you should restrict yourself by not using Javascript for your Website – only reason may be that you don’t have any use for it.

EDIT: a different question is: If you should provide some minimal functionality of your web site when your visitors don’t have JS enabled – that’s mostly a good idea, for the reasons some of the commenters have pointed out.

EDIT2: surely for every web site, one has to find a balance between user-friendlyness, search-engine-friendlyness and development effort. IMHO today Javascript can help to improve that balance – if used wisely. Said that, I think there is no need to generally minimize Javascript usage today any more to keep that balance. Use it with care, and don’t demonize it.

Having a site that can be used without JavaScript means that it is available to the widest possible audience. While it’s true that the majority of browsers support JavaScript and the majority of users leave it on by default, you can’t count on that for sure. Not everything that accesses your site is a browser after all; if you want your site properly indexed by search engines such as Google, then GoogleBot needs to be able to navigate your site without JavaScript.

There are also specialist pieces of web browsing software where JavaScript is unavailable or doesn’t work as expected. Screen-reading or Braille software used by the visually impaired, for example. There are also environments where memory is constrained and having vast amounts of javascript may make the browsing experience unpleasant or even impractical, such as smartphone browsers.

You should look into the concept of “progressive enhancement”, where you build a site to work without javascript, then add a javascript layer on top to improve the user experience. That way you’ll have a site that is at least usable to people without javascript.

You don’t need to strive to provide every possible feature you’re planning to implement with JavaScript to non-JavaScript browsers, but it’s still important to at least leave the basic use cases available without JavaScript. Being able to browse the site is obviously top of the list, but if you’re building an e-commerce site, making the checkout process JavaScript-dependant would be silly as it could cost you sales.

The other answers seem to be focusing on “should I not ever use JavaScript”, so I think they’re missing the point. You shouldn’t use JavaScript if you don’t need it. Some people use JavaScript for everything:

• Hover effects (should be CSS)
• AJAX (should have href when reasonable)
• Positioning (should be CSS)

The benefits are things like:

• The site displays faster
• CSS is significantly less complex than JavaScript most of the time
• Having backup href links helps search engines, users who want to open links in other tabs, and users who hate JavaScript

Of course, AJAX is pretty cool, and so are dynamic pages, so don’t throw those things away just because some people don’t need them.

My point is, learning how to do things without JavaScript is good, minimizing JavaScript is good, and having a backup for when JavaScript doesn’t work is good, but there’s no reason to avoid features because they require JavaScript.

It’s a good idea to avoid unnecessary functionality, period. Frameworks like jQuery make it incredibly easy to add frills that may make sense to add, but sometimes don’t. For instance:

Do you really need to animate that?

… or …

Is traversing the entire DOM really needed for such a trivial selector? Could you limit it using context, and do we need that in the first place?

I would not avoid using JS, but I do take care to not be obnoxious, while looking out for slower machines. The same holds true with some of the fancy new stuff we get in CSS3 – like drop shadows … if used excessively they can make someone on a lower powered machine have a really bad experience.

The exception to this might be writing front end controls for various kinds of appliances, where they must absolutely work with JS disabled (perhaps a strict security policy on a data center management network dictates no JS). So the above should be taken in context with whatever requirements you have.

I believe that being a relatively new and young web developer ( about 4 years), I had to research a lot on this since javascript is everywhere.

What I try to do on my projects is to make sure that the site functions without javascript, then add javascript where it makes sense (client side validation, UI improvement, etc). It is a sort of progressive enhancement and it takes care of SEO, disabled javascript and older browser incompatiblities.

This same question has been asked on SO, but I cannot for the love of me remember where.

JavaScript usage can be limited in several cases:

• Validation. It has to be done on server-side. Sometimes in web applications there is a quick client-side validation, but it alone isn’t enough.
• Extremely important tasks. Users can choose to disable their browsers’ scripts, so the JS code will not work at all. If you want to be sure that something will work in any case on any browser, don’t trust it to JS.
• Speed. The JS code has to be sent to client, and the more code you write, the longer it takes. Though small amounts of code will have no practical effect.

JS has a huge bunch of features, which can’t be replaced by server-side code. Other than those above, I don’t think there would be any reasonable argument to limit JS usage.

“Database driven websites” is the key to the answer. There are two ways to create websites, and the amount of Javascript allowed depends on which one you’re using, really. You can build:

1. Content-centric websites. In the first case, the magic words are “progressive enhancement”; limit javascript to redundant functions that can be supplied with classic accesss to content through plain HTTP.

2. Web applications. For applications, you’re using the web as a software platform instead. Apps rely on some assumptions on the software available – modern browsers, latest versions of popular javascript libraries, desktop accesss with mouse and/or tablets with multi-touch.

The web as a software platform

Minimum accesss requirements are OK if you’re really building an application – you target some specific platform to gain advanced features that couldn’t be built otherwise. It’s just like developing for Python or Java or .Net. Don’t let buzzwords like HTML5 and the promise of “run anywhere” fool you; you can have portable code between devices only as long as the whole platform is supported on those. Any change to the development stack, and the software will break.

Thus the price to pay is that you’re following a moving target, as new versions of the platform are released; you’ll have to play catch-up to keep your app working as the platform evolves. The only benefit you get is a semi-universal delivery mechanism for your app that doesn’t depend on packages nor application stores; but you lose the main feature that differentiates the web from previous networked computer systems.

The web as content delivery

Content-centric websites are a different beast; they are in the tradition of the classic World Wide Web. Content is loosely interpreted by the client, which can made any desired transformation before presentation. The site is expected to be accessed by an ecosystem of different platforms that may or may not support the current standards:

• Mobile devices supporting less than the latest and most expensive bells and whistles
• Old browser users who can’t (at the enterprise) or don’t know (at home) how to update
• Future versions of popular engines that deprecate their old APIs

You’ll lose them all if you require the current breed of javascript, which is always evolving. In this context, broken javascript that prevents accessing the content is a sin.

Everyone saying that “javascript usage should be minimized” is advocating this style. It’s OK to include some JS, mind you, but all functions should be redundant with basic accesss to content that could be achieved server-side:

• Data entry validation
• AJAX updates of content for quickest navigation (that nevertheless works without JS)

The benefit to this approach is less testing and upgrading required, and more shelf-life. The first static webpages from 20 years ago are still browsable in any web client, but the first web applications are forever broken. If your site has any archiving value at all, you’ll benefit in the long run from using the web as a content delivery system, not an application platform.

I work for my state government, and as a result most of my development involves data-driven interactive websites. Queries against historical data, form submissions, things like that. We keep our Javascript to an absolute minimum, for the following reasons:

1) Validation of form inputs should always happen on the server side, never on the client side. If you attempt to validate your inputs on the client side, all a hacker has to do is create a local copy of your web page and re-write the Javascript to allow what he wants to send you (SQL injection, etc). Your validation must take place somewhere under your exclusive control, i.e. on the server.

2) Many users either turn off Javascript or use a browser that may not implement it properly. Being the government, we have to support everyone, even if they’re using really REALLY old equipment. HTML works everywhere; Javascript, not so much. By not using Javascript in your web pages, you give them a really small footprint on the client machine, using few resources. This maximizes the number of people who can access your content. For the same reason, you shouldn’t get too nutty with your CSS. Keep it simple, keep it clean, and let little old ladies see your site even if their computer was bought in 1999 (Incidentally, we do get tech support calls from people like this).

3) Javascript, being a tool favored by “web developers” rather than server-side programmers, tends to be pretty ugly. And designers (which is what web developers usually are, if you want to be honest about it) tend to not see the problem with downloading “scripts” from random places on the web. They say things like “why reinvent the wheel?” and “Not Invented Here”. So instead of writing their own code, they often just go out and grab something from another site, thinking that if it’s on the internet it’s fair game. There are two problems with this: A) they might inadvertently post some malicious Javascript that takes you a while to catch, and B) they might run afoul of someone’s copyright, and get you sued. Both situations are to be avoided.

IN GENERAL, Javascript is a bad idea. Client side code of ANY kind is a bad idea. The client side should only contain markup language and CSS; let the server-side handle the heavy lifting.

It depends.

While desktop user agents can be expected to support and run your javascript in a meaningful way, not all user agents are graphical desktop browsers, and you need to decide whether you want to cater for them.

Examples include:

• search engines (Google does run some javascript, but certainly not all of it, and if you rely on javascript for navigation, search bots might not find all of your content)
• aggregators and scrapers
• text-based browsers (not many people use those, though)
• screen readers and other reading aids
• (some) mobile browsers

My rule of thumb is that if it’s a web application for regular users (in-house, community, that kind of thing), then relying on javascript is OK, but if you want to be publicly accessible and findable, then at least the vital functionality should work flawlessly without javascript, and you should fail gracefully when you need it, rather than exhibiting ‘undefined’ behavior.

Old-fashioned approach is totally outdated. For example I’ve made an ajax-deletion for moderator on one of the sites and he is just happy because of the obvious speed increase.

Of course developer can do two versions both for JS and non-JS users, but in most of the cases it’s extremelly expensive and doesn’t worth 1-2% of the website audience (if you are not Google, of course).

So my answer would be NO — JavaScript is the answer for many user-experience questions, why shouldn’t I use it?

From my experiance there was a time when companies disables JavaScript by policy. But this time is far gone. Currently I have build some big intranet applications and webapplications for bigger global companies. For all applications, the usage of JavaScript and JQuery was part of the things that the customer expectets.

Building applications for customers is not only speed and security anymore. Customer want to focus on usability and the usage of AJAX technology. Without the usage of JavaScript it would not work such good. PostBacks all the time for some very small tasks like calculation or something like that is for most companies not an option.

When we think about the current situations in bigger companies there’s a another indicator why JavaScript is currently a must have. Look at the CMS systems which are currently running in business. Most of them using Microsoft SharePoint or Adobe CQ, some of them Drupal or any other and so on. All this systems relies on JavaScript. Without javascript most of the application would not work, as the user expect it.

In times gone by, JavaScript was used and abused, and scripts were (perceived to be) full of vulnerabilities, and a source of malware.

Many corporate networks responded by disabling JS, a policy that (rightly or wrongly) still exists in many organisations today.

Quite simply, I suggest that no site should rely on JS to operate

As most of the answers here explain, using javascript is no harm. If you want to save your coding and messy looking source code, try coffee-script which will save a lot of effort typing javascript.

http://coffeescript.org/