Getting Good with JavaScript - Andrew Burgess [29]
How can you do this? Well—and I hate to sound like a broken record, but—here's another place that anonymous, self-invoking functions are really useful. If all your code can be contained in one place, you can do this:
(function () {
// all your code goes here
}());
This way, you don't have to worry about anyone getting at your variables; they are all safely tucked away inside the scope of the anonymous function. And since functions can access the variables in the scope outside them, you can access any global variables that other libraries set.
But what if you're writing a library, or some similar code that needs to be accessed outside of itself? In cases like this, you'll have to use a global variable. That's not a bad thing, as long as you name and set it properly. You'll probably want to use the module pattern for this if you want to have your private variables and methods. Then, assign a returned object or function (depending on the complexity of your library) to the global variable.
I prefer to give my global variables all uppercase names; I do this for two reasons:
It makes it clear to me when I'm reading my code that it's a global variables.
It reduces the chance of having that variable overwritten, because most libraries don't do this (yet!).
You might want to adopt this principle.
The Good Parts and JSLint
Here's a dirty secret I've been hiding all along the way: JavaScript has bad parts. There are several terrible features in JavaScript that you should never ever use. I haven't mentioned any of these anywhere at all in this book, so you currently have a relatively "pure" understanding of JavaScript.
ROCKSTAR TIP
Don't misunderstand me here: this doesn't mean that if you hear about something not mentioned in this book, it's a bad part; I just couldn't fit it in! Check out the appendices for more great resources and topics you should look into next.
However, you should really know about the bad parts, eventually. I really recommend you get Douglas Crockford's book JavaScript: The Good Parts. It will do more than just teach you what's naughty and what's nice about JavaScript. You'll really be taken to a new level of JavaScript understanding.
Once you've read the book (or even before!), you can run your JavaScript through JSLint, Douglas Crockford's JavaScript code quality tool. At the top, paste in your code. Then, at the bottom, choose the best practices you want JSLint to check for. If it finds places where you aren't using those best practices, it will let you know.
Fig. 4-3. JSLint
Remember, your code will probably still run, even if it doesn't pass the JSLint test. This is just a self-check. Also, realize that there are several very reputable JavaScript developers who don't see eye to eye on everything Crockford calls a Bad Part. Ultimately, you'll have to weigh both sides and decide what's right for yourself.
Optimizing your JavaScript
We talked a bit about how one JavaScript file is better for your site visitors than multiple ones. There's something else you can do to improve the time it takes your site to load for a visitor: JavaScript minification. The idea here is that every byte counts when a site visitor is downloading the JavaScript file. To improve that time, we can take out all the whitespace (spaces, tabs, line breaks, etc.) and shorten all the variables names, since these extra bytes are really just there to make our jobs easier, and aren't necessary for the code to run properly.
So, when you're website is finished, you can go through your code and take out all the whitespace.
Actually, that's not necessary. There are command-line tools that do this for you. Since this is only a significant benefit if you have a lot of JavaScript, I'll leave it to you to explore this topic more. You can check out JSMin, YUI Compressor,