Definitely my favorite article in 24ways till now :) Thanks.

For the “it’s all about timing” section, I find it much easier to simply place the Javascript under the objects you wish to affect. This way, there’s no interference with other scripts, and there’s no waiting for big images to load before executing it. Because the browser loads it in logical order, it won’t ever execute it until everything above it has loaded.

That’s a good point, Lewis. The way we do it at Yahoo! is to place the JavaScript as low down in the body as possible, ideally just before the closing body tag. Not only is this useful for doing away with onload events, it also has benefits in perceived page load time. Browsers tend to hold off loading other things whilst JavaScript is downloading, so if you have the script tags at the bottom, the user at least has something to look at whilst the download occurs.

That’s an optimisation you can make, but first it’s important to understand and master the most common methods, I think.

Great article. Unfortunately there are very few good javascript resources. Thanks for the tips!

Thanks — great article!

Cool! – much appreciated…

Every so often, whilst browsing for resources in web technologies such as JavaScript, you come across something which is just obviously logically CLEAN. This article, for me, is one such site. Cuts to the chase at the right level and in the right area. Excellent. Many thanks.

I’m relatively new to javascript (working at it for six months or so) and have recently wanted to start getting into the world of javascript objects. Thank you so much for such a well written and useful introduction.

Nicely done.

These pointers will definitely help me get back up to speed.

Great article, Drew! I really enjoyed the part of keeping everything private. Definitely saves tons of debugging time down the road as apps get bigger. One thing I would have add/clarified in the “Event Handling” section is handling non-JavaScript users. Responsible JS developers should always keep these users in mind. Jeremy Keith mentions several ways to do this in his blog and in his Dom Scripting book for those interested. Thanks!

Actually, that “general pool of variables” is the window object. You can easily test this by defining a function (for example: “foo1”) and then checking on the value through the window object: “window.foo1”. You’ll see that both “foo1” and “window.foo1” are the same. The same applies for all predefined window methods and properties (and thus window.open(...) = open(...)).

Nice indeed.
Clean and understandable.
All thumbs up – good work.

Specially the “private” part will be useful for me in future projects.

Thanks! Very helpfull article.

great practical for doing great javascript. your articles are always worthy, thanks. ;)

Here’s a useful link which explains all about using private, public and privaliged methods and variables, which I found seriously useful. The only thing you can’t really do, is have a protected method/variable.

http://phrogz.net/JS/Classes/OOPinJS.html

Enjoy!