Java Script Abuse

If you have a boring, static web page, there are 2 ways to liven it a bit with some dynamic JavaScript:

add JavaScript, so it looks about the same as before to people who have JavaScript turned off.
replace with JavaScript, so it looks worse, perhaps completely unusable, to people who have JavaScript turned off.

Both ways look identical to those who have JavaScript turned on.

It should go without saying that the first way is the RightThingToDo?. But far too often, well-intentioned people do it the second way.

(EditHint: Is there some other wiki page here on "Curbing JavaScript dependency"? Or am I just remembering that article from http://herd.plethora.net/~seebs/ops/ibm/?)

You must be thinking of BrowserAbuseSyndrome. Should we apply RefactorByMerging?

Someone claims, "If you run JavaScript, you're highly spammable. Just switch it off, then complain to the webmasters who rely on it for core functionality."

I am astonished to discover that http://nasa.gov/ now has this message to those of us who don't have JavaScript enabled: "The nasa.gov site requires that JavaScripts be enabled in your browser. For instructions, click here". Usually ".gov" sites are better than average at accessibility.

Taking a well-intended feature and warping it, e.g. JavaScript's ability to create popups - occasionally very useful when writing a web-based UI, but hugely irritating when used to cover your screen in porn when you've accidentally typed in the wrong URL.

THE POWER TO DO ANNOYING THINGS DOES NOT MEAN YOU HAVE TO!!!

Absolutely. This is JavaScriptAbuse again.

Reminds me, those web sites that use client side JavaScript to check that the form is correctly filled in, and even precalculate some of the fields, are probably asking for trouble. Big trouble if the server is relying on the checks, else most likely a violation of OnceAndOnlyOnce.

Second that. I've lost count of the number of times I've explained to various different coworkers why a JavaScript validation can be helpful to the user in reducing the number of round trips that are required, but is utterly undependable as a business rule or security check to the server's application.

Client JavaScript and Server code are different packages on different machines, usually in different languages. OnceAndOnlyOnce doesn't apply, though you have the added job of keeping changes synchronized much as you do with ftp and ftpd. The main reason for using JavaScript for client-side validation and contextual morphing is that it makes life better for the user. Making it easier once for one programmer is trumped by making it easier many times for many users. I wouldn't be the first one to point out that good user interfaces are often a pain in the butt to build--anything of quality usually is. -- MarcThibault

My favorite example of the dangers of JavaScript validation without server-side backup has to be the one mentioned in this Daily WTF entry - http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx - in which Google's spider ended up deleting numerous pages of content from a CMS because only JavaScript was used to guard against deletions... --CodyBoisclair

My problems with JavaScript as it's seen on the Web today:

It's used to do things which are useless and/or scary. For example, printing out a message telling the user what browser and OS they are using. It's bad enough if the rest of your webpage design cares in the slightest about that; writing that data back to the user makes it appear as though the FBI is watching or something. Plus, these "script kiddies" never bother to format that data, so it all appears in this one cryptic string. My guess is that this is because they're all employing CopyAndPasteProgramming, and the original version didn't include any formatting because the original author meant it as "just a test".
It's used to do things that used to be covered perfectly well by CGI - or even by HTML itself. I deeply resent being asked to use my processor to do whatever calculation to determine the name of the file to display. You're the one providing the service, you figure out the filename on your CPU. Worse yet, the JavaScript in these cases often takes its data from forms, which look identical to forms that issue a CGI request.

You are choosing to view the page, so why don't you use your CPU? This argument makes no sense. Besides, choosing to do it via CGI instead just means you end up using your bandwidth instead of your CPU. Six of one...

Speaking of gathering browser/OS data - it's used to collect aggregate information on a site's users - such as whether or not they support JavaScript. The reality is that god-only-knows what percentage of users out there have JavaScript disabled normally for whatever reason (I do it to avoid popups because my browser is old and doesn't let me disable popups specifically, and also to decrease memory footprint; other people may be able to give other good reasons); all the surveys say everyone can handle it because the surveys are 100% self-selecting - something that no-one working for the website ever seems to realize. So you get everyone continuing to use their stupid JavaScript toys because it's "virtually guaranteed" it'll work. Free hint: CGI works even if the user is running Lynx or Mosaic or something equally ancient.
It's used - I swear I am not making this up - to prevent HTML documents from rendering. Even though JavaScript is not actually later used in any way whatsoever.

Seriously. I have seen stuff in page source like

 <HT
 <script language = "javascript">
 document.write("ML>");
 <!-- rest of document, with no javascript or anything in it>

Absolutely zarking ridiculous. -- KarlKnechtel

Concur. People who put Javacrapped like that in their pages should be drawn and quartered by extra-large turtles. At least they should lose all their web clients and never be able to foist such an abortion off on the Internet consuming public ever again.

My beau and I hate it when copying some text from a web page is disabled by JavaScript. The script captures mouse events or something so that you cannot select text on the page. I installed JayEdit on his machine and taught him some HTML so that he can get around this. Studying the page source is easier for him than disabling JavaScript (a real pain in InternetExplorer 6), and he doesn't run into the trouble of forgetting to re-enable JavaScript for reading his e-mail. Personally, I hate this abuse because it means I cannot select text for my screen reader to read to me unless I disable JavaScript (easy in MozillaFirefox). -- ElizabethWiethoff

Don't forget the pages where some nimrod has decided that he doesn't he doesn't want those pesky inter-web pirates stealing his precious photos, or what have you, and is using something that prevents you from right-clicking the page. Usually by displaying a dialog box with an annoying message whenever you do it ("that'll teach 'em!"). Evidently these nitwits have never considered (a) "Save page as...", (b) drag-and-drop of images straight out of the browser, (c) the user disabling JavaScript, or even (d) that maybe the user is using the context menu for something that has nothing to do with saving pictures at all, you zarking idiot. Sigh.

What's really ridiculous is when these pages contain the HTML comment

Luckily for the rest of us, these people all use InternetExplorer, so they don't even know that other browsers now contain an "Allow scripts to disable context menus" preference that can be unchecked.

[Moved from elsewhere]

JavaScript is the wrong way to do form validation. You have to check again on the server (you can't trust the client), so you have to make the same tests in two places (client and server) and (usually) in two different languages, which is a nightmare to maintain. And sometimes there are tests you can do only on the server. Looks like client side validation is PrematureOptimization...

A good 75% of JavaScript form validation code is buggy and extremely annoying - often featuring such gems as error dialogs that pop up if you try to move between form fields without filling them in a particular order. Anything that beeps and flashes at me whilst I'm still filling the form in I instantly class as MalWare. Server-side validation is (i) easy and (ii) more reliable than any JavaScript implementation - because for anyone using Lynx, links or w3m (for example; or they might have JS switched off in their browser) JavaScript will not work, resulting in a useless website and a deeply frustrated user. The programmer also benefits, because they can use a programming language that they can actually rely on. I speak from the perspective of someone who has been paid to build a few websites, using both methods of validation - and also as a user who has experienced enough shoddy JavaScript to last a lifetime. -- EarleMartin

JavaScript form validation can also be deeply embarrassing for the page supplier, because casual inspection of the source often reveals staggering incompetence of the page's development and support organization. For example, the email forwarding page for Comcast.net once contained "validation code" that disallowed domain names containing a hyphen. Because it's JavaScript, the bug and its fix was obvious. Even after reporting the bug and its fix, it took Comcast more than a year to it. -- TomStambaugh

What would help would be a development framework that composes both server- and client-side validation mechanisms from a single validation specification (which also serves as the definitive statement of what "valid" means for a given datum, independent of implementation); you rely on the server-side validation, but when the client is also validating you still get the time and bandwidth savings.

{I tend to use server-side code for complex validation and client-side for the more simpler stuff. For example, if we want to validate that a valid URL has been supplied, then the client-side can check that it contains at least one of "http" or "www." but not get into detailed parsing. Leave the server side code to do that. This reduces the client-side code, which reduces both browser-version-specific issues/bugs, and reduces the form download size. Most end-user mistakes surrounding URL's would be in putting non-URL's in URL fields and vice verse. Thus, the server side wouldn't be involved very often such that it's not taxed. But you do want to make sure the server-side validation is a super-set of the client side, otherwise hacks and JavaScript crashes may deliver bad data. Below is a rough rule-of-thumb summary. -t}

  Frequent user error and easy to code: client-side
  Infrequent error but involved to code: server-side
  Complex code but frequent error: usually server-side, but ItDepends.
  Low-volume data entry: server-side. (Not worth bothering with client-side validation. KISS.)

If you cram in a lot of widgets into a page, you risk the equivalent of DllHell. For example, one widget may use a different version of JQuery than another such that one or the other or both get foobarred because you can only install one version of the library per page. PHB's who keep demanding stuff often trigger such problems.