Uncle Billy

Real-world example of why global variables are bad

billy — Wed, 28 Jan 2009 04:15:08 +0000

We all know that global variables are bad. Sooner or later, someone is going to pick the same name for a variable as you do, and when that happens, *poof!* your code doesn’t work anymore.

Unfortunately, not every programmer understands why globals are bad. This is a write-up of a rather spectacular bug that I was asked to look into during my glory days at InternetBroadcasting. It involved tracking down a conflict between an advertisement on the same page as a Microsoft VirtualEarth map control. Needless to say, when we contacted Microsoft to make them aware of the problem, they were less than responsive… it was easier to talk to the small ad serving company to get them to fix their part, and that was ultimately the route that the project manager decided to take to fix the problem.

What the problem was

A bug was reported wherein a Microsoft VirtualEarth map would not display on certain web pages that contained a certain advertisement.

How it happened

In summary, the problem occurred because two third-party JavaScript files were included on the same web page, and both scripts contained code which did not follow the extremely important best practice of limiting the use of global variables.

JavaScript code included from Microsoft’s VirtualEarth library defined a global variable named “g.” JavaScript code from ContextWeb sourced in for an advertisement also defined a global variable named “g.”

There can only be one global variable named “g” on any given web page. In JavaScript, the last value assigned to a variable is always the current value. Here is the order of events as they happened on the websites that experienced this problem:

A script tag loads Microsoft’s VirtualEarth library, wherein a global “g” is defined.
```
/* This runs in the global space, i.e. outside of any function or object */
function g(a){
        return new Gimme.object(Gimme.query(a))
}
```
(as found in http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6.2)

A script tag loads in ContextWeb ad code, wherein the global “g” is overwritten to a new value.

/* This runs in the global space, i.e. outside of any function or object */
var g=''; /* Here is the initial overwrite... many follow below... */
var k='';
var j='';
var tw=w;
try {
	k=d.location;
	if(k==top.location){
		g=k;
	} else {
		while(true){
			g=tw.document.location;
			.............

(as found in http://tag.contextweb.com/TagPublish/getjs.aspx?action=VIEWAD&cwrun=200&cwadformat=728X90&cwpid=501657&cwwidth=728&cwheight=90&cwpnet=1&cwtagid=25722)

A script initializes the VirtualEarth map, which attemps to use the variable “g.” Having been redefined, the variable does not contain what VE code expects it to, and the map cannot be created.

Why it happened

A typical problem when integrating two third-party JavaScripts into the context of a web page is a global variable conflict. A global variable is one that is available to all scripts running in a particular context. In a web browser, all global variables are members of the object called “window,” and can be referenced simply by typing the name of the variable. Because JavaScript allows one to rewrite or delete variables created in this space, one can define and rely on a global variable and have that variable overwritten by another script which naively uses the same variable name.

Many of today’s most respected JavaScript developers recommend against the usage of global variables (for example, see Douglas Crockford’s take on the subject). Unfortunately, the usage of globals is rampant. The reasons for this are many, including that:

global variables are convenient
It is extremely easy to use a global variable, and many online tutorials unfortunately contain examples wherein globals are used. Many first-time programmers are taught to use a procedural programming style with JavaScript and to write just enough code to get the job done (without namespaceing or context-checking).
JavaScript programmers are relatively inexperienced
JavaScript has only recently emerged as a programming language for web applications; in the past, it has been used for very simple tasks on web pages. Now that it is being used to write full-blown applications, problems such as global variable conflicts become extremely serious. Lacking understanding of best practices, even programmers who are fluent in other languages can make terrible mistakes in JavaScript.

the language has some confusing syntax that promotes the use of global variables

In the global space (i.e., outside of any function or object) any variable defined with the var or function keyword is global. This is what happened in the case of VirtualEarth and ContextWeb. For example:
```
function f() { ... }
var t = 4;
alert(typeof window.f); /* "function" */
alert(typeof window.t); /* "number" */
```

Inside a function, the declaration of a variable without the keyword var makes the variable global. Programmers new to JavaScript often are not aware of this. For example:


function myFunc() {
	/* LOCAL VARIABLES */
	var myVariable = 3;
	var myFunction = function() { return 3; }

	/* WHOOPS - GLOBAL VARIABLES */
	myOtherVariable = 4;
	myOtherFunction = function() { return 4; }
}
myFunc();

alert(myVariable); /* undefined */
alert(myOtherVariable); /* 4 */
alert(window.myOtherVariable); /* 4 */

alert(myFunction()); /* error, myFunction is not defined */
alert(myOtherFunction()); /* 4 */

How it could have been avoided

Namespacing
In JavaScript, the practice of namespacing is simply creating one global variable that is unlikely to create a name conflict (such as the organization name of a company in capital letters). All variables are then stored within that object, and can only be accessed through the object. For example:
```
var IBSYS = {};
IBSYS.foo = 3;
alert(foo); /* undefined */
alert(window.foo); /* undefined */
alert(IBSYS.foo); /* 3 */
```
Scoping
Javascript allows the creation and immediate execution of unnamed (i.e., anonymous) functions. Functions have their own local scope, and thus any local variables defined in an anonymous function will not conflict with any globals or code in any other scope. For example:
```
(function() {
	var t = 3;
	alert(t); /* 3 */
})();
alert(t); /* undefined */
```

Kentucky Derby Pie

billy — Wed, 24 Dec 2008 03:18:37 +0000

I love this pie! It is a family favorite, which we always make on Thanksgiving and Christmas. I’m immortalizing the recipe here for my own sake; I keep losing the one my mom gave me. I’m quoting this directly from: http://www.nickers.com/kentucky-derby-pie-recipe.htm

1 Pie crust

Filling:

1/2 cup butter, melted and cooled

2 eggs

1 cup sugar

1/2 cup all-purpose flour

1 cup semi-sweet chocolate chips

1 1/2 cups chopped pecans

2 tablespoons Kentucky Bourbon

Beat eggs with cooled butter. Add flour & sugar. Beat until mixed well. Stir in pecans, chocolate & bourbon. Pour mixture into pie shell. Bake at 350° for about 30 minutes, or until set.

PNG background-image support in IE6 – better late than never

billy — Mon, 08 Dec 2008 16:53:00 +0000

My buddy Drew Diller (who is a freaking CSS genius) has come up with a clever solution to get CSS backgroun d-image support working in IE – including background positioning and repeating. If you are tired of using AlphaImageLoader and want something easier, check this out:

http://www.dillerdesign.com/experiment/DD_belatedPNG/

It lets you use a PNG image as a CSS background-image property in IE6 without much fuss at all!

Enterprise JavaScript build system – Sysbliss

billy — Wed, 03 Dec 2008 03:59:18 +0000

I’ll soon be working on a screencast for the JavaScript build module that Jonathan Doklovic wrote for his enterprise build system (which leverages Jira, Bamboo, Ivy, and Ant). The JavaScript module takes advantage of JsUnit for unit testing, YUICompressor for compression and lint checking, and JsDoc Toolkit for source documentation.

I’ve also contributed a Flex build module to this system, and hopefully it will be put through the paces soon so that any major deficiencies can be exposed and worked out.

JSUnit XML to JUnit XML

billy — Tue, 08 Jul 2008 03:31:34 +0000

We’re using JSUnit to run tests in our build system, and we’re using Bamboo to do continuous integration. Unfortunately, the XML spit out by JSUnit is not recognizable as JUnit XML for the purposes of integrating into Bamboo. I wrote this XSL stylesheet to transform the JSUnit XML report into a JUnit XML report that Bamboo can parse. It’s simple and inefficient, but hey, if you are looking at this, you probably just want to get the job done (like I did).

View jsunit_to_junit.xsl

Type enforcement and argument validation in JavaScript saves time

billy — Wed, 21 May 2008 03:09:54 +0000

Debugging JavaScript is hard enough – but it is especially annoying when you have spent a good amount of time tracking down a bug and it turns out to be a type error (i.e., your function expected a Boolean true but got a String “true”). Perhaps your value was implicitly cast to another type by some operation, or maybe you forgot to pass the right arguments to a method. In a statically-typed, compiled language (such as AS3 or Java), you would find out about bad arguments during compile time – and you’d probably get a nice, descriptive error message of what was going on. Not so with JavaScript – in fact, because it is loosely and dynamically typed, you may not find out about your bad argument until you waste an hour or two tracking down a bug.

To avoid this sort of thing, you can throw your own errors when a method or constructor doesn’t get what it expects. The pattern is easy to get the hang of. The very first time you get one of these errors, you will feel good about all this extra typing.

/**
* A function that creates a new barf bag.
* @param {Boolean} zip          Whether this bag has a zipper or not.
* @param {String} bagType     Valid types: "paper"|"plastic"
* @param {String} vomitType  Valid types: "chunky"|"bile"|"watery"
*/
var VomitBag = function(zip, bagType, vomitType) {
   /* validate arguments */
   if(typeof zip != "boolean") throw new Error("VomitBag: expected zip to be Boolean");
   if(typeof bagType != "string" || !(/^paper$|^plastic$/.test(bagType)) throw new Error("VomitBag: expected bagType to be String and to be either 'paper' or 'plastic'");
   if(typeof vomitType != "string" || !(/^chunky$|^bile$|^watery$/.test(vomitType)) throw new Error("VomitBag: expected vomitType to be String and to be 'chunky', 'bile', or 'watery'");

   /* some code... */
}

This technique is not at all new to JavaScript. For example, Marijn Haverbeke talks about it briefly during a good writeup about error handling in Eloquent JavaScript: Error Handling – Eloquent JavaScript (that whole site is worth reading).

Disabled form element and dispatchEvent bug in Opera

billy — Mon, 19 May 2008 18:41:18 +0000

I’ve stumbled across a bug in Opera 9.27 (which I dutifully reported). Basically, if you disable a form element and use the DOM2 dispatchEvent method on the element to simulate a click, the element fires the event. Since the element is disabled, it should not fire any click event handlers – this is the behavior in Firefox and Safari. Here’s the html I used to prove it:

Opera disabled form element / dispatchEvent test

Encapsulation vs. Efficiency in JavaScript

billy — Wed, 14 May 2008 23:22:55 +0000

I’m an encapsulation fanatic. I love to write code where data is protected from view and unavailable for mischief. I like the ability to react to changes to the internal state of a function. Also, the thought of something accessing and re-writing a method or variable on another class instance scares me, and I’d rather just not let it happen. A ton of my code ends up looking like this:

var Cookie = function() {
   var chips = {};
   this.addChip = function(type) {
      chips[type]++;
      bakeCookie();
   }
}

On the other hand, there are quite a few times when I’m writing JavaScript that I wonder when I should be worrying about efficiency. It’s an obvious fact that using prototype methods can increase efficiency by reducing the amount of memory and processing required. I’ve always assumed (from doing very short, non-scientific tests in a browser) that this technique pays off only when using many instances of a particular object.

var Cookie = function() {
   this.chips = {};
}
Cookie.prototype.addChip = function(type) {
   this.chips[type]++;
}

You might as well not even have the addChip method at this point. Anybody could come along and change chips – hell, they could turn it into a number or something.

Without the ability to maintain privacy, you won’t ever know when your properties change (in case you want to do something when one changes). Without privacy, you can’t hide your implementation details and provide a clean interface (in case you need to re-write the guts of your function) without a guarantee that nobody has latched onto one of the properties or methods you don’t care about anymore.

This is one of the most frustrating things about JavaScript for me. For performance, we are forced to make a decision wherein we must sacrifice privacy. Personally, I don’t use prototype methods all that much – until I know that a class I’m using will be instantiated many, many times, it just doesn’t make sense to me to lose all the benefits of privacy. Performance be damned – hell, from what I heard, you are supposed to optimize as a last resort, anyway.

I’d love to hear what other people think, though.

Script Everything

billy — Wed, 07 May 2008 04:33:07 +0000

One of the neat things I learned at the last No Fluff Just Stuff conference I went to was from one of Neal Ford’s Productive Programmer seminars. Script everything. I’ve been using this as my mantra lately. Why should I do steps a, b, c, d, e, f, and g again, even if I only do the task once a day or even once a week? I’m still looking for a script to help me remember stuff, like car keys and feeding the cats.

Use only the JavaScript that you need

billy — Mon, 07 Apr 2008 03:14:14 +0000

I am a person who likes to use JavaScript development frameworks, such as Prototype or JQuery. There is a time and a place for such things – as when developing your own website or working on some code that relies on lots of UI bells and whistles (fade outs, complex event handling, etc). On the other hand, when I’m writing code that is going to end up as a distributed application, such as a widget, I don’t think that using a development framework is appropriate. There are a few reasons for this:

Serving only the code that is used saves user time – less downloading and less parsing.
Part of developing JavaScript applications is accepting the fact that you don’t know where your code is going to run. You should maximize compatibility.
Frameworks make hard things easier to code – but not necessarily faster to run.

I’ll start with the first point: serve only the code that you use. Even when I’ve used a framework heavily on a project, it seems like there is about 60% or 70% of the framework that is useless to me. Why should I bother with that crud? Most of the time, it makes more sense to steal code from one framework or another to accomplish what I want to do. More often than not, the problem I’m faced with can be stripped down to the statement: “I need a cross-browser way to do ‘x.’” If that’s all I need, I’d rather solve it myself through some simple research, or steal code from someone who has already done the research, such as PPK. The ugly truth is that JavaScript developers need to think about bandwidth and processor overhead. Not all users are running their browser on “decent” hardware and a fast connection. There are no hardware requirements for JavaScript! Sure, you need a web browser with a JavaScript interpreter – but that includes such a large swath of browsers and versions of browsers that it’s literally a crap shoot.

Second point - maximizing code compatibility. I disagree with using a framework that pollutes the global scope in such a manner that it can break others’ scripts through its mere existence. I am specifically referring to the Prototype library, which adds methods to native objects such as the Array object. Of course, when you know where and how your code is running, use what you want. I happen to think Prototype is a great library, and that the people working on it are incredibly smart. On the other hand, if your code is supposed to run on a bunch of other sites, you should try to write it so that it doesn’t pollute and possibly break other scripts. These days, there are tons of authoritative sites to find a cross-browser way to solve your particular problem. You can steal code from a framework, Google the problem until you find a good snippet, or learn about the issue and come up with your own solution. Using a library to solve only a few of these problems is heavy-handed if you are expecting a large amount of traffic on your particular project.

Lastly - frameworks make hard things easy to code, but not necessarily faster to run. For example, take the JQuery library. It’s extremely useful to be able to query the DOM in the CSS/XPathy kind of thing that JQuery implements. On the other hand, if you are not concerned with the manner in which the library accomplishes what you ask it to do, you are asking for trouble. The classic example is running a class name query on a large node set. Yuck – that can take eons to complete in Internet Explorer! Granted, it’s not JQuery’s fault that your code is inefficient – but if you had gone through the trouble of selecting all nodes and checking each class name to see if it matched what you were interested in, you’d quickly see that you were being inefficient. When you use one of these libraries, you are tempted to use the concise, convenient syntax without caring how it works. Understanding how it works, though, is the only way to understand how to use it efficiently.