Later on, browsers begin to support these attributes even in other tags like <div>, and pretty much anything else.

However, as web standards develop over the years and people’s coding practices for the web begin to standardize, it is generally considered bad practice to use them. There are many reasons for this, among others:

1. You cannot attach more than 1 action this way. If you want to do a lot of things in one event, you will need to put a lot of code either in this attribute, or in the function being called from this attribute; and these may very well be unrelated actions. This makes your code less organized and harder to develop.
2. No good separation of presentation (HTML) from functionality (JavaScript). Everything is mixed together. This makes collaboration development efforts difficult; and makes the code hard for you to manage even if you were the sole developer.

Fortunately, we have an alternative solution. They are Event Listeners.

Event Listeners basics

Event listeners are initiated strictly in JavaScript code, not within any HTML tags.

For the remaining of this article, I will assume the use of the Prototype.js framework. I’m aware that there are advanced developers who dislike this library, but it is used fairly commonly (either completely, or their own in-house modified version) among a lot of startups and web apps, so hopefully it’s not unreasonable to depend on it.

With that in mind (with the inclusion of Prototype.js), you can initiate an event listener like this. Assuming you defined a function for handling the “click” event on a div block with an id “main_div”:

var handlerFunction = function(event) {
alert('Hello world!');
};

var my_box = document.getElementById('main_div');
Event.observe(my_box, 'click', handlerFunction);

The main idea is very simple. It is simply this: instead of using onclick (or on-* of any event) in any HTML tags, you have Event.observe in your JavaScript code instead. This way, you can add as many different functions as you like to any elements. They can even come from different .js files. (for more details on how to use Event.observe, see the Prototype.js documentation.)

To see what kind of events are available to you other than “click”, see the DOM Events W3C spec. What you will often be using are in section 1.6.2, mouse events.

Page loading, and Initialization routine

If you understand what the above code means, you can also logically deduce that, your event handler does not start being observed until the point this JavaScript runs. And whether you want it or not, when the Event.observe line executes, it will start.

The implication here is that, it is entirely possible that your HTML document is not ready to handle this. This is because JavaScript runs linearly as your HTML file is being loaded and parsed.

More often than not, your JavaScript resides in the beginning of your file. (It is recommended for web developers to keep their JavaScript at the top) That means you don’t even have any objects on your HTML page yet! Your Event.observe line is sure to fail, because the object by the id “main_div” does not exist yet.

So should you put your JavaScript at the end of your page instead? Of course not! What you want is a way to run all your Event.observe lines after your page is fully loaded.

Event.observe(window, 'load', function() {
Event.observe(my_box, 'click', handlerFunction);
// ... any other event listeners go here
});

Once you have this in your JavaScript, all your event listeners will only initiate after your page is completely loaded. The way this works is simple. The “window” element means the entire browser window. The ‘load’ event for this element means that this handler function will execute when the page is done loading. So the effect is that all your interactive elements on your page will start being interactive when the page is fully loaded.

DOMContentLoaded

But there is still a problem! The key word in the last paragraph was “fully loaded”. What this means is, your interactive elements only work after your entire page is ready. Unfortunately, this means after all images and other binary data have finished loading. When your web page is heavy with data, this might be a long time. If you use event listeners for your navigation dropdown menus, for example, that means they are not going to work until all your images are done loading. It would be very annoying if a user cannot use your navigation menu before the page finishes loading.

*This is why I wrote this article!* The key point is here.

Fortunately, thanks to many wise web developers on the internet, we now have a solution. This solution lets you initialize your event listeners as soon as your HTML finishes loading, and without having to wait for images and all other data on your page.

The solution: DOMContentLoaded.

In simple words, this events.js library will let you do this:

addEvent(window, "DOMContentLoaded", function() {
Event.observe(...);
// ...
});

What will happen now is that, all your event listeners will initiate as soon as the HTML of your page is loaded, without having to wait for anything else. I am not going to go through the details of how and why here (I try to make my blog as close to practical usage lessons as possible without being too academic). If you are interested, the link I gave you above should give you every detail you want.

Conclusion

With all of the above knowledge, there is absolutely no reason one should be using the old ways of “onclick”, “onmouseover”, etc. anymore. Many people attempt to use event listeners, but oftentimes they encounter the problem I stated above of elements having to wait for the page to be fully loaded to become interactive. This has turned many people back to using the old-school methods, which is unhealthy. After having introduced you to DOMContentLoaded, it should solve all concerns you have with using event listeners.

In JavaScript, “null” is not the same as “undefined”.

This was what costed me some debug time recently when working with JavaScript at my job.  I will talk about how I came across this issue, because there are various valuable aspects of this story that could be worth reading for those of you frontend developers.

Actually, scratch that, if you don’t know about jslint, do read the following section too. It is useful, and you won’t regret it.

jslint

First of all, most of you know that JavaScript is a pretty loosely-enforced language.  Most browsers out there (IE, Firefox, etc.) are pretty tolerant to sloppy code, just like HTML. To be fair, it’s not the browsers’ faults completely, since in a lot of cases, JavaScript was defined to be like that. For example, it tolerates missing semi-colons at the end of a line. Nonetheless, JavaScript is very powerful, despite these problems that make programmmers cringe. Here’s a good read: JavaScript: The World’s Most Misunderstood Programming Language.

The problem comes when there are multiple browsers. Each can interpret things a little differently. With Firebug and Venkman, it’s easy to develop for Firefox and pinpoint errors. (I personally just use Firebug, in the short time I’ve tried Venkman, I found it too complicated.) For IE, this is a lot harder. The best free tool I’ve found is MS Script Debugger (free but requires genuine Windows ), possibly along with IE Developer Toolbar (completely free). IE Developer Toolbar is similar to Firebug, but without the JavaScript part. (only CSS and DOM inspecting)

With simple JavaScripts, debugging is usually not a problem. But when you get into object-oriented JavaScript, involving code spreaded out to many files, (IE’s internal-secret-line-numbering doesn’t help) it’s a nightmare. Couple this with the fact that IE has their own strange interpretation rules, you often cannot find where errors are happening.

Fortunately,  Douglas Crockford developed an extremely useful tool, called jslint. It’s even web-based (developed with JavaScript itself!), so you don’t have to install anything. All you do is copy and paste your JavaScript in there, and let it validate. Kind of like a w3c validator for HTML, also kind of like a compiler for C++. The lint program is/can be very strict on your code — this means if your code passes jslint, it is extremely likely that it will work fine in all browsers including IE.

Data types comparisons

In JavaScript, there are a few basic data types you’ll be using a lot, such as integers, strings, booleans. Because of the loosely-enforced nature of JavaScript, comparisons are made to be loose as well. To give an example of what I mean:

var mynum = 0;
var mybool = false;
if (mynum == false) // this evalutes to true
if (mybool == 0) // this evalutes to true

They are all the same in “value”. To further enforce your code logic to make sure you’re doing what you want to do, jslint recommends using === or !== to check for equalities/inequalities when one side involves zero, false, null, empty string, etc. The === or !== operators also check the data type. To give an example, continuing from above:

if (mynum === false) // this evalutes to false
if (mynum === 0) // this evalutes to true

Once you understand this part, let’s move on to the next section.

“null” and “undefined”

In JavaScript, they are different. Null is a value that is only assigned by a programmer. You can set a certain variable to the value null. Undefined is what a variable has if it wasn’t assigned to anything.

I had no idea about any of this before, so I googled it up and found this article: JavaScript Difference Between null and undefined. It has a clear and simple example to demonstrate the point. To be more specific about the kind of problems I ran into, we had something like this in our code.

myFunc = function(arg1, arg2, arg3) {
if (arg3 == null) {
// do something
}
};

This was working fine at first. If you call myFunc without arg3, it goes in the conditional statement and executes whatever is inside. When I ran the code through jslint, and changes the check to (arg3 === null) as it recommends, problems arose. It never went into that condition anymore and the bug travelled very far along the code to some weird behaviors. (because this function happened to be the constructor for a class in our case, making it hard to find at once)

I eventually realized that, when you don’t pass in arg3 to myFunc, arg3 then has the value “undefined”. The value, without the type, is the same as “null”. Initially, it worked fine when we only use ==. But when we add in type-checking, with ===, they are not the same. Thus, the code needed to be fixed to say:

if (arg3 === undefined)

Conclusion

It was a good lesson to me. Even though I’m coding up object-oriented JS left and right, there are still basics about the language that I admit I’m not familiar with. I learned something, and I hope you learned something out of this entry as well.