All JavaScript should be contained within it’s own JavaScript file/files that should be included at the top of the user interface:
Bad:
<script type="text/javascript">
/* Lines of JavaScript Code */
</script>
Good:
<script type="text/javascript" href="scripts.js"></script>
Inline JavaScript Function Calls:
Bad:
<a href="#" onclick="somefunction('value1')" title="some">Link</a>
Good:
<a href="something.jsp" id="object1" title="some">Link</a>
The good example has the onclick functionality added dynamically from the JavaScript, for example using code like:
addEvent(document.getElementById('object1'), click, function{
somefunction('value1', 'value2', 'value3');
});
Objects can be directly referenced using ID’s, looped through using Class name, found through the DOM, or any number of other techniques for finding elements. Yet it is dynamic and content dependant.
Unless you are working in a guaranteed 100% JavaScript enabled user environment. Even then, complex AJAX style interaction can lead to slow loading, slow reacting, confusing user experience. JavaScript’s strength is as a behavioral UI enhancement tool.
Curly Brackets: Every { needs an }
Quotation Marks: Every ” needs a “
Parenthesis: Every ( needs a )
Script Tags: Every <script type=”text/javascript”> needs a </script>
Line Ends: Every line needs to end with a ; (this is not always critical, but it is an indicator of deeper issues).
Using Firefox, open the user interface you want to view, then open the JavaScript Console (under tools), select there should be nothing under the “Errors” tab and little or nothing under the “Warnings” tab (sometimes warnings can be misleading – but in the main they are bad).
Both of these measures are one way and result in additions that are lost in the scope. Using DOM based content addition/removal results in cleaner, more navigable code. The only area where document.write is good, is for writing out content that needs to be included in the head when the JavaScript loads, for example JavaScript can generate the include tags that load CSS for layouts that are dependent on JS to function – users with JavaScript disabled will get the vanilla user interface CSS.
When you activate a trigger, do you get a visual indicator that ‘something’ is happening? A common AJAX issue, is clicking a trigger to get a behavior and getting no visual indicator that the application is doing something. In traditional applications this occurs with the user interface refreshing, in AJAX the user interface does not reload, often this visual cue is not included, which leads to user frustration that the application is not responding.
Can you crash a web based application by clicking on lots of links that contain JavaScript behavior before they have a chance to finish complete? This is another common AJAX issue, with the Asynchronous nature of the interaction, it can often be possible to click a trigger and while it is processing, click another trigger and suddenly the two actions collide and application crashes, or reacts in an unexpected fashion.
Sniffing for browsers based on specific browser header information is unreliable and easily tricked. A prime example is the Opera Browser, which allows the user to pick what User Agent values it will pass to the browser when it views a user interface. Opera can pretend to be IE, yet it won’t act like IE. For this reason, checking for the browsers ability to perform a function is the preferred method of coding for cross browser.
This is difficult to quantify into easily identifiable signs. But some things to look out for are: