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 JavaScript''''''s 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: 1. 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". 2. 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...'' 3. 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.'' 4. 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 document.write("ML>"); ''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. ---- See also * FormOverContent * JavaScriptSucks * JavaScriptSucksInBrowsers ---- CategoryJavaScript CategoryWebDesign