The easiest way to play around with JavaScript is to use Firefox combined with the Firebug plug-in. There are also some solutions for Internet Explorer if you're running on a platform that supports it. In this chapter's code, we'll sometimes assume we're in the Firebug console, allowing us to type in and execute code immediately. The rest of the code will be run inside a webpage. It will usually be obvious from the context.

Modern JavaScript supports Unicode. Prior to ECMAScript v3, Unicode was allowed only in comments or string literals. Modern browsers (in theory) allow Unicode to be used anywhere, even in variable names. Personally, I'd avoid Unicode except in comments or string literals, but that may just be paranoia on my part.

Whitespace is ignored in JavaScript, except inside string literals. However, you can use the "" character to continue a line, including in the middle of string literals. This will not insert a new line in the string.

var s = "Hello, 
world!";
alert(s); // Will alert with the string "Hello, world!".

To make JavaScript easier, it was decided that semicolons at the end of statements should be optional. This can lead to some strange issues, as they can be inserted by the JavaScript compiler in places where we don't necessarily expect. The return, break, and continue statements are the primary culprits. The canonical example is the following code:

return
true;

This will be interpreted as:

return;
true;

This is almost never what we mean. The answer for this is to always use semicolons, and never rely on semicolon insertion.

JavaScript has both null and undefined values. Variables declared, but not initialized, are undefined, not null.

Both == (equal) and === (strict equal), and their negated (using a prefixed !) counterparts may be used for equality operations. They behave differently. The equal operator does type conversion, the strict equal operator doesn't. We'll briefly examine type coercion later. In general, we'll usually want to use ===. Equal (==) and strict equal (===) also behave differently when comparing null and undefined values. With ==, null and undefined are equal, whereas with ===, they are not.

The || (logical OR) operator can be used to ensure a variable has a value.

var aVariable = anotherVariable || "Default value";

If the value of anotherVariable is null (or undefined), the value of aVariable will be set to"Default value", else it will be set to whatever there is in anotherVariable. This is a very common shorthand notation for the following code, and is seen a lot in good JavaScript code.

var aVariable;
if (anotherVariable == null) {
aVariable = "Default value";
} else {
aVariable = anotherVariable;
}

The same thing can be represented using the ?: operator as:

var aVariable = (anotherVariable == null) ? "Default value"
: anotherVariable;

We can also express this by using JavaScript's liberal notion of truthiness:

var aVariable = anotherVariable ? "Default value"
: anotherVariable;

JavaScript has only a few data types when compared to Java. One important difference is that variables in JavaScript are not statically typed. This implies that a variable initialized to a string in one place can be assigned a number somewhere else. Doing this is rarely a good idea, and can be a source of frustration.

aString = ["lots", " of", ..., " strings"].join("");

s = s.replace(/<pre.*>/i, "").replace(/</pre>/i, "");

var array1 = [1, 2, 3, 4, 5];

var a1 = [1, 2, 3];
a1[a1.length] = 4; // a1 now contains [1, 2, 3, 4].

a1[8] = 42;

Values can be added to objects at any time. For example, we could add an arbitrary property to the aDude object after it's created by using either dot notation or array notation.

aDude.newProperty = "I'm a new property.";
aDude["anotherNewProperty"] = "Another new property.";

Properties may be accessed using either dot or array notation.

We'll explore this further as we go along. However, note that we can use a function as a value in an object. In other words, functions can be the value of a variable. Functions are first class objects in JavaScript.

aDude.toString = function() {
return "aDude [fname=" + this.fname + ", lname="
+ this.lname + "]"; }
alert(aDude); // Alerts "aDude [fname=Dave, lname=Newton]".

Notice the this keyword used in the snippet. It is similar to Java's this, but significantly different depending on the situation in which it is used (we'll talk about this a bit later). A complete treatise of JavaScript OOP is well beyond the scope of this book, but we'll cover some basics.

Objects can be created by dedicated creation functions. This methodology can be used to make sure objects are always created in a specific way, are assigned default values (if no specific value is specified), and so on. We'll learn more about JavaScript constructors a bit later on (they're also just functions, although not the specialized ones within a class as in Java).

function makeAdude(fname, lname) {
return { fname: fname, lname: lname };
}
var aNewDude = makeAdude("Omar", "Velous");
aNewDude.fname; // Returns "Omar".

Here, we're simply returning an anonymous object from our function. However, the function ensures that at least the object's fname and lname values are initialized.

Function parameters, like all JavaScript variables, are untyped. In addition, we can call a function with fewer (or more) parameters than listed in the function definition.

function f1(param1, param2) {
...
}
f1(); // That's fine: param1 and param2 are undefined.
f1("foo", "bar", "baz", "plugh"); // That's fine too...

This alone can make JavaScript a bit tricky at times, but that's the nature of the beast. We can always check for a specific number of parameters. We can even check for their types to a degree. However, this is surprisingly uncommon (at least to Java programmers).

Parameters that don't receive a value from the function call are undefined, not null. Recall that using == (equal) will not show the difference between undefined and null, whereas using === (strict equal) will show the difference. For example, if we called the function with a single parameter:

f1("hello");

Inside f1(), the parameter param1 would be filled with"hello". Param2, on the other hand, would be undefined (not null). If null was a legitimate value for param2, we might need to distinguish between null (implying the parameter was potentially passed) and undefined (implying that the parameter wasn't passed in).

Using the || operator allows us to supply default parameter values if we don't receive one in the call. For example, let's assume the param2 parameter is optional. When it's not provided, we'll supply a default value of 42 as shown here:

function f1(param1, param2) {
param2 = param2 || 42;
...
}

Accessing arguments beyond those listed in the function definition resembles array access, but only in appearance. Functions receive a pseudo-parameter named arguments. It acts like a JavaScript array in a way that we can access its length property and elements using array notation's [] (square brackets). However, the arguments value does not inherit Array's methods like join, sort, and so on (it's not an Array, but is dressed as one).

function f1(param1) {
var anArg = arguments[1] || "Default value";
...
}

function f1() {
var csvArgs = Array.prototype.join.apply(arguments);
alert(csvArgs);
}

function f1(param1, param2) {
if (arguments.length != 2) {
alert("Error!");
return;
}
...
}

function f1(param1, param2) {
if (arguments.length != f1.length) {
alert("Error!");
return;
}
...
}

As a variable can hold a function, we can define a function at any place where a value is expected, including inside other functions.

function f1() {
function f2() {
alert("Meh.");
}
f2();
}
f1();
f2(); // Will this work? Nope.

Function f2() is not available once we've exited the f1() function, for two reasons:

This is one way to hide functionality to avoid conflicts with our own or third-party JavaScript libraries. We'll also learn some other ways. However, this is still an important aspect of functions that comes in to play occasionally, and can always be used when a function needs to be used only locally, or we want to restrict its usage.

Closures are one of the terms often used by programming language junkies. They're an extremely powerful concept, occasionally difficult to grasp, and capable of both wondrous and terrifying behavior.

To put it briefly, closures are functions evaluated in a context containing other bound variables. In some ways, it sounds more complicated than it actually is.

What this actually means is that an inner function (as described in the previous section) has access to the variables from the outer function. As a simplistic example, consider the following:

function f1() {
var s = "Hello";
function f2() {
alert(s);
}
f2();
}
f1();

Although this is not particularly useful, it illustrates the point. How can we make this useful? One key consideration is that the inner function will maintain its reference to the outer variable's value at the time of the outer function's invocation. Here's a canonical example of closures, which highlights this feature:

function makeAdder(x) {
return function(n) {
return n + x;
};
}

The makeAdder() function relies on two things:

We can then call the function returned by makeAdder(). It will add the value of x, passed to makeAdder(), to the argument we pass to the function returned by makeAdder(). Remember what I said about headaches? This is much easier to demonstrate than to explain:

var add10 = makeAdder(10);
add10(1); // Returns 11.
add10(32); // Returns 42.

The code above creates a function that will add the value passed to makeAdder(), to any value we pass to the function created, by calling makeAdder(). As the value x passed to makeAdder()is unique to each invocation, we can easily make functions that add different values to their arguments.

var add10 = makeAdder(10);
var add30 = makeAdder(30);
add10(32); // Returns 42.
add30(12); // Also returns 42.

Again, the makeAdder() function itself isn't particularly useful, but the idea of closures is an important concept that can be used to neatly encapsulate functionality and reduce code size in many situations (we'll see closures again in a little bit).

We can model classical inheritance in JavaScript using functions and the new keyword. It will look different from what we're used to, and it may not be the best way to program JavaScript. However, it's used to a considerable extent, and hence it's important to understand the mechanisms.

Instead of creating a class, we'll create a function. However, to differentiate it from a normal function, we'll call it a constructor function and name it starting with an upper-case letter. This is a convention, not a rule. However, for Java programmers, it helps ease the transition into what is ultimately a very different programming paradigm.

Like Java, JavaScript has a this keyword. However, it is used differently depending upon context, and there are some restrictions regarding when it can be used (and how it will work). We'll get to one of the bigger issues with the this keyword in a bit. For now, we'll assume we can use it in a somewhat similar way to how we use it in Java.

function OurFirstClass(aParam) {
this.aParam = aParam;
}

We can use this in our JavaScript code by applying the new operator to the OurNewClass function.

var inst1 = new OurFirstClass("Hello");
inst1.aParam; // "Hello"

function Pseudo1() {
function aPrivateFunc() {
...
}
this.aPrivilegedFunc = function () {
...
}
}
Pseudo1.prototype.aPublicFunc = function () {
...
}

var inst1 = new Pseudo1();

inst1.aPublicFunc();
inst1.aPrivilegedFunc();

Pseudo1.prototype.aPublicFunc = function () {
alert("aPublicFunc");
this.aPrivilegedFunc();
}

this.privilegedFunc = function () {
alert("privilegedFunc");
privateFunc();
this.protoFunc();
}

function Pseudo1() {
var that = this;
function aPrivateFunc() {
alert("aPrivateFunc");
that.anotherPrivilegedFunc();
that.aProtoFunc();
}
this.anotherPrivilegedFunc = function () {
alert("priv2");
}
this.aPrivilegedFunc = function () {
alert("aPrivilegedFunc");
aPrivateFunc();
}
}
Pseudo1.prototype.aProtoFunc = function () {
alert("aProtoFunc");
}
var inst1 = new Pseudo1();
inst1.aPrivilegedFunc();

We've seen some hints about the prototypal inheritance of JavaScript above, when we created a function on a class's prototype:

Pseudo1.prototype.aProtoFunc = function () {
alert("aProtoFunc");
}

This is another way to add functions to a class. Each instance of Pseudo1 will have a aProtoFunc function. How is this used for inheritance? Let's say we want to subclass Pseudo1, a subclass named (uncreatively) Pseudo2:

function Pseudo2() {};
Pseudo2.prototype = new Pseudo1();

If we create an instance of Pseudo2, we can call aProtoFunc() on it:

var pseudo2 = new Pseudo2();
pseudo2.aProtoFunc(); // This works.

Pseudo2 may contain its own methods, defined using either its prototype or in the Pseudo2 function body (using the this keyword, as seen previously). Creating subclasses this way is a bit unwieldy. There are several ways to make this more concise. The canonical method uses a function to encapsulate creating the subclass function, setting the prototype, and returning an instance (the following is Douglas Crockford's version):

function object(o) {
function F() {}
F.prototype = o;
return new F();
}

The easiest way to isolate our JavaScript code is to just put it inside an anonymous object. This is the tactic taken by many major JavaScript libraries, and is wonderfully simple. For simply isolating functions and variables, it's a reasonable technique. It's also safer than putting all of our functions and variables into the global namespace.

As a simple example, we might create an object named MOD1 for the JavaScript specific to a given page. It doesn't matter what we call it, but it should be unique on the page.

var MOD1 = {
myAlert: function (s) {
alert(s);
}
}

We'd then call the myAlert() function by prefacing it with the module name.

MOD1.myAlert("Hi!");

This way, if any other JavaScript loaded after ours has a function named myAlert(), our page's myAlert() won't be replaced by the newer definition. It's hidden inside the MOD1 object. We only need to refer to it through our module.

In the next chapter, we'll return to this methodology and see how it can be broken down depending on our requirements, and learn some additional modularization tricks.