if (myReturnValue) {...}
//inside a condition, undefined, null and '' (empty string) - they all are equivalent to boolean false.

But that is only half the truth. It is very important to know that the following statements return false.

(undefined == false);
(null == false);
('' == false);


(but, ironically (undefined == null) returns true)

This knowledge becomes critical when you are comparing two unknown return types. So, whenever you must compare these three values against each other or with boolean false, the best way is to add ! (NOT) (or !! – double NOT) operator to both the operands. This will ensure that both the operands are boolean before the comparison happens. Now, try the following; they all return true.

(!undefined == !false);
(!null == !false);
(!'' == !false);
(!undefined == !''); //yes, it does return true
(!undefined == !''); //and that, too


What’s wrong with this approach of assigning handler to an event? If you ask me, I can think of at least 4 reasons not to follow it.

1. It looks really ugly.
2. If multiple programmers are working on the same interface, there might be situations you won’t be aware of other pre-existing event handlers to the same DOM element. The above method is a sure-shot way to override existing handlers.
3. What if I want to have multiple handlers for the same event on a DOM element? Yes, with tricks it can be achieved (by retaining the existing event handler). But even a novice programmer can guess the trouble one can get into as the number of handlers goes on.
4. Let’s assume you assign 5 event handlers using the above method to the same element. Now, you want to remove the third one (random). There is no way you can crack this without modifying all instances of event handler assignment.

So? This is exactly why DOM 2 events module introduced a standard and more manageable approach for assigning handlers to an event.

function attachEventListener(domElement, eventName, eventHandler) {
    if(window.addEventListener){        // Mozilla, Netscape, Firefox
        domElement.addEventListener(eventName, eventHandler, false);
    } else {                            // IE
        domElement.attachEvent("on" + eventName, eventHandler);
    }
}

Now,

var myButton = document.getElementById("myButton");
var myButtonClickHandler = function(e) {//do something};
attachEventListener(myButton, "click", myButtonClickHandler);

Can an anonymous function be used here instead of a function reference? Not a good idea. If at a later stage, if a particular handler is to be removed, you must have a reference to it which can be passed to removeEventListener (Mozilla, Netscape, Firefox) or detachEvent (IE).

An elaborate explanation on this topic can be found at http://www.howtocreate.co.uk/tutorials/javascript/domevents.

Let’s analyse why people come to our home page. To see the cool graphics work we put there? To see what the website is all about, its features? To become a member? To login, if they are already a member? We might get assertive answers to each of these questions; but which ‘Yes’ is the most important one? Of course, the numbers will say it all.

The most popular example to consider here would be Gmail. Like any other service, it too, highlights the main features on the homepage but has placed the login form right there opened and focused (read that as ‘ready to type in’).

I really appreciate one web-based email provider for the user experience it has in offer; it is awesome but it gives me hard time whenever I switch between computers. From the home page, I have to click on the ‘Login’ link and wait for separate login page to load. Why? I can’t reason. And what occupies the home page? Eye pleasing graphical work that explains how the product works and its features make it better than others. But do I have to bother about that now? I am already a member!

Some websites take the middle route – they provide a popup based login form. So waiting for another page to load is avoided; but user still needs to click on the ‘Login’ link! And sometimes even have to click on the Username field to focus and start typing. Ah!

Unless login isn’t required to access the content or avail the services on the website, 9 out of 10 times, if not more, people come to the home page to login. Login! Login!!

It is very natural to have some cool, fancy stuff on the home page, highlight the product features etc., so let it be but don’t ignore the user for that. Give her the first thing she wants – the login form. Home page IS THE PLACE to have the login form. It can further be improved by setting the focus on the Username field by default.

Many banks offer lesser loan interest rates for new customers; we don’t have to be alike. Let’s care for what we already have; our existing users!