If a website needs interactive content on a page, it usually comes in the form of either JavaScript or Flash - where JavaScript runs in the visitors browser without the need of a propriety plug-in.
It was originally created by Brendan Eich at Netscape, and was first released in December 1995. Although the syntax of JavaScript is similar to Java, they are two different languages, that work in different ways. For example, Java programs are compiled to byte-code and delivered as programs, whereas JavaScript is an interpreted language which typically has its source code delivered and executed in a web browser.
It is important to remember that some visitors may have a browser that does not support JavaScript, or they may have chosen to disabled it. In terms of percentages, it depends on the websites target audience, I would suggest that 7% of visitors will not have JavaScript support... perhaps the most noticeable user being the search engine spider.
Corporate computer users are the most likely type of visitor to have JavaScript disabled. This is because they are usually running an old browser which cannot be upgraded, or where their companies IT department may have disabled JavaScript due to security concerns.
Originally security issues came from the browsers, where the first implementations of JavaScript had several security holes. Fortunately most of these issue have been fixed by the use of sand-boxing. However, there are many websites out there which are vulnerable to Cross-Site Scripting, and its because of these potential issues that most IT departments have decided to disable JavaScript to protect their users.
Although, this does not make Flash a better alternative, it also suffers from the same problems and has an extra step requiring the visitor to have the Flash plug-in installed, of which not every user can do - for example corporate users may not have the required permissions, or the Flash plug-in might not support their Operating System.
To cater for the visitors that do not have JavaScript, it is still possible to create websites so that they are not broken, this is called graceful degradation.
Using a pop-up window as an example, some website authors create them in such a way that they do not work in non JavaScript browsers:
<a href="javascript: window.open('a.html');">...
In this case, browsers without JavaScript support will take the value from the "href" attribute, then instead of executing it as Javascript, will instead try to load it as a URL. However, if the code was changed to:
<a href="a.html" onclick="window.open(this.href); return false;">...
The browsers with JavaScript support will execute the instructions in the "onclick" attribute to create a new window, whereas browsers without JavaScript support will just ignore the "onclick" and simply link though to "a.html". Admittedly this approach will not open a new window for all visitors, but its better than the link being broken.
Making these types of changes should fix most support issues for JavaScript, however it can be taken one step further. Using a coding style known as Unobtrusive JavaScript, it is possible to remove all JavaScript from the HTML and get the JavaScript to apply itself onto the web page when required. So going back to the pop-up example, the HTML source code could look like:
<a href="page.html" class="popup">...
In this case we are using the class attribute to mark the link as being a pop-up, the CSS can target it (if the website author needs to use special display properties), and once the page has loaded, the JavaScript can also find all the links with the "popup" class and add the relevant event handlers. See the example on pop-up windows for more information.
By using either of theses methods to give a "graceful degradation" quality to a website, it allows all visitors to use the website, but those who have JavaScript available will, in theory, have a better experience. This is usually better than creating a Flash website to get the required effects, as with a Flash alternative, it tends to create two versions of each page, which can drastically increase the time to make any changes.
Another potential use for JavaScript is to validate data in forms before they are sent to the server. By doing this, it can make the detection of errors much faster, as it does not require a call back to the server.
It must be noted that this is absolutely not a replacement for server side validation. This is because it is really easy to bypass JavaScript validation with tools like the form faker, although this tool was built purely for development purposes, it can be used to demonstrate how JavaScript validation only creates the illusion of security.
Another issue with JavaScript validation is that it can go wrong, sometimes a browser might not understand a command and could fail in such a way that makes it impossible for the website visitor to submit the form. An example of this is when a field is removed from a form and the website author forgets to remove the JavaScript validation for it. Although its possible to write JavaScript to handle this situation gracefully, it is still possible that an error could completely break the form, even when the data is perfectly valid.
Screen reader users also can have problems if JavaScript is used in this way. If the user of this software cannot visually see the page, they go to submit the form and wait, typically they expect a new page to load, but nothing happens... this is usually because the screen reader has not detected that the current page has changed. So after waiting to be sure that the server is not taking a long time to respond, the visitor has to re-read the whole page looking for something that has changed, if the only thing that has changed is something visual, like the use of a red background on fields, then how are they supposed to find out something is wrong?
Most of the time, it is because of these issues that the additional work associated with JavaScript validation does not make it worthwhile doing. It is usually allot simpler to use the server side validation to re-deliver the page. If most people are submitting data that does not meet the validation requirements, then perhaps the fields used on the form need to be re-considered.
Despite what some website authors are making out, AJAX is not revolutionary technology, it simply allows a website to send a request to the server and receive a reply without the need to load a new page. Because the whole webpage does not need to be re-loaded, it can make the interaction with the server much quicker, with the added bonus that because its "Asynchronous" it allows multiple requests to be made for independent parts of the page.
The ideal use of this technology is when updating small areas of the page with values from the server, it makes a great tool for website authors to use, when its relevant. Unfortunately several websites are overusing the technology just because they can, in several cases the use of traditional links or forms is perhaps a better alternative.
Normally overlooked when using AJAX is being able to create a bookmark for the current page or send a link to a friend. If the whole website uses AJAX technology to load every page, then the value in the address bar is typically for the homepage. Having a "perma link" on a page does not always solve this problem, as it expects the user to find and know how to use it.
Also, if the the website does not degrade gracefully for browsers that do not support JavaScript, then visitors may not be able to access certain parts of the website - imagine a search engine spider not being able to index the content on your website.
There is also the history stack to consider, with AJAX requests, because they are not individual pages being loaded, the browsers back and forward buttons are usually broken. One solution is for the websites author to include their own back and forward buttons on the page, but how is the user expected to realise that the buttons provided in their browser, which they already have experience in using, will not work on the current website? will they notice the "site specific" history links, and instantly know how to use them?
Ideally, if you are showing different pages to the user, then loading a new page with a normal link is the best thing to-do, especially considering that the new page HTML is typically quite small anyway, more so when the CSS and JavaScript is stored in external files that can be cached by the browser.
Any feedback would be greatly appreciated, I don't include comments due to the admin time required, but if you email me, I will reply and make appropriate updates. Also, if you would like to take a copy of this article, please read the terms this article is released under. This article was originally written Monday 4th December 2006 and was updated on Sunday 12th August 2007.