Getting Good with JavaScript - Andrew Burgess [28]
This is a pretty rough and dirty way of testing; it's primary appeal is that it's quick and easy. It's really not very scientific. If you want to do some real performance testing, you'll want to check out JSPerf. This site will comprehensively test your code, as well as keep track of the score in all the browsers you test in. Let's see how it works:
Here's what you'll see on the home page:
Fig. 4-2. JSPerf
It's pretty simple: just go down the form and put in your code. There's a place to put in any starting HTML or JavaScript code that's needed for the test, but isn't part of the code you want to test. Then, you add a title for each test code snippet and fill in the code. You can have as many test snippets as you want. When you're done, hit "Save Test Case." You'll be taken to the test case page, where you can run the test. Hit run test, and wait. It will run the test, tell you which code snippet was fastest, and by how much. Then, it stores the results from your browser in a table below, so you can compare different browsers. Just copy that URL and try the test in a different browser, to see how it performs. Note that JSPerf shows the results as "Operations Per Second"; therefore, a higher number is better.
JSPerf tests are publicly visible, so you can see what tests other people have run.
Organizing your JavaScript
There's more to programming that rapidly smashing your fingers against the keyboard. There's the meta part, like the number of files you put your JavaScript code in, or how to organize the code within those files. These are things beginners often don't think about, so let's take a look at them.
One File, or Many?
Let's start with files. As you know from Chapter 1, JavaScript code is stored in a file with the extension "js"; you also know that there are two ways to include JavaScript in your web page:
Because it's wise to separate your content and functionality, the first method above is better practice. But should all your JavaScript go in one file? Or should you separate it into different files?
When you're coding, it's definitely easier to break that code into several files. Since JavaScript global variables (the ones outside functions) are available from a global object accessible everywhere that JavaScript is on the page, you can create variables in one file and access them another, as long as both files are linked to in your HTML.
However, splitting your JavaScript into several files comes with a cost: that cost is paid by your website visitors. Here's why: for every file their browser needs to download, it is downloading more than just the code. There's the overhead—like HTTP headers—that comes with the file. Because of this, it's much better to store all your code in one file, to minimize the amount of overhead.
The best medium here would be to develop your code in separate files and then concatenate those files together when you're ready to publish the site. There are programs (such as build scripts) that can help you automate this process. This might be a bit beyond your skill level at this point, but if you're ready for it check out my tutorial on using Ant to compile and compress JavaScript, published on Nettuts+ (See the section below for more on compression).
Global Variables
By now you're familiar with the concept of global variables. You might think this is a great think, since everything is always accessible. However, that's not the case. Here's why: the more you write JavaScript, the more you'll find that the code you use on a given page isn't just yours: you'll use libraries, helper methods, and other code from other developers. If your site has advertising, you'll find that many advertisers insert their ads via JavaScript. If all the code relies on global variables, there's a really good chance