Question

I’ve heard that global variables in JavaScript are bad, and I can understand some of the namespace issues, etc. But why shouldn’t I use a global variable for something that never gets changed throughout the script–like the date? (Which changes day to day, of course, but only ever gets referenced and not changed throughout the script.)

Answer 1

You can use globals if they are protected in what you think is a unique namespace and are only used when beneficial. The main issue is that globals can make one piece of code more likely to conflict with some other piece of code (if not using different namespaces or very unique names). For this reason and others, it is best to avoid globals when they are not actually needed (when variables declared local to some scope would work just as well), but there are still some appropriate reasons to have globals. The main point of education is that many people use globals when they are simply not needed. If you need them or find they are more efficient, then you can use them just fine as long as you protect the namespace from accidental collision.

I personally create one top level, global object and hang all my other globals off that one object.

Some other issues with globals:

1. They are slower to access in Javascript than locals because they are the last ones found as the interpreter looks for a given variable name in the various scopes that it might exist in. Usually not a noticeable problem, but something to be aware of. Here’s a jsperf that shows how much of a difference there can be.
2. If you have any asynchronous code that modifies globals or timer-driven code that modifies globals and more than one asynchronous operation can be in flight at the same time, the multiple async operations can step on each other through the modification of the same globals.
3. Globals are often not declared near the point of use so reading code can be more challenging.
4. Globals are generally not shown automatically in the debugger (the way local variables are) making debugging a little less convenient.
5. IE automatically defines a bunch of global variables based on some names in the DOM which can conflict with your own global variables without you realizing it.
6. A simple omission of the keyword “var” on a local variable makes it a global variable and can confuse the heck out of code if that name is already being used as an intended global variable. I’ve seen this happen on the for (i = 0; i < m.length; i++) construct before. It can be tough to track down what is wrong.
7. Global variables persist for the life of the script. If one is using a global variable to hold an object reference for something that doesn’t need to exist for the life of the script, this can cause the script to use more memory than it otherwise would.
8. Global variables in a browser exist in the scope of the window object so they can conflict not only with other globals, but also anything else on the window object.