A function declaration is the most common way that JavaScript developers define a function. You’ve seen it many times before in tutorials, in books and on websites teaching the basics of the language. It looks like this:

function greet() {
    alert('Hello!');
}

A function declaration always starts with the function keyword and is always named. According to spec, the following code should throw a syntax error although in reality some browsers accept it as a valid statement:

function () {
    alert('Hello!');
}

Conversely, if a JavaScript statement begins with something other than the function keyword, like in the following code sample, then according to the syntactic rules of the language it cannot possibly be a function declaration. In these situations the definition is instead considered a function expression.

var appreciate = function () {
    alert('Thank you!');
};

The major difference in behavior between function declarations and expressions is that declarations are hoisted to the top of the scope in which they reside while expressions are not.

Another difference is that a function defined as part of a function expression need not be named. We’re free to provide a name, but this is useless in most situations – at least in my own personal experience – because the name is meaningful only to the code within the function definition itself:

var f1 = function f2() {
    alert(f2);
};

var a = f2; // a is undefined
f1(); // alerts the function definition

We can also create a function expression by wrapping a function definition within a pair of parentheses. The parentheses are known in JavaScript as the grouping operator, and they’re used to indicate the correct order in which expressions are evaluated. According to the language’s syntax, they can only contain expressions so the JavaScript parser considers any function definition within parentheses to be function expressions rather than function declarations.

Immediately invoked function expressions

If we follow an expression with a pair of parentheses, the JavaScript parser expects that expression to represent a function definition that it can invoke.

var halve = function (n) {
    return n / 2;
};
halve(8); // returns 4

Since a function definition wrapped in a pair of parentheses is just one form of a function expression, we can follow it with a pair of parentheses in order to invoke the function immediately after we define it. This is known as an immediately invoked function expression.

Immediately invoked function expressions are incredibly useful in unobtrusive JavaScript programming because they provide a way to create a private scope in which variables and functions are kept out of the global namespace. In the following example, we create a library variable that acts as a private namespace in which we can define code that is hidden from

var box = (function () {
    var contents = [];

    return {
        insert: function (thing) {
            contents.push(thing);
        },
        count: function () {
            return contents.length;
        }
    };
})();

box.insert('abc');
box.insert(123);
box.insert({ width: 640, height: 480 });
box.insert(document.body);
box.insert(function () { alert('Hello!'); });
box.count(); // returns 5
console.log(contents); // throws a reference error since it can't find the 'contents' variable

Because immediately invoked function expressions accept arguments like any other function we can also use them to essentially save the state of a variable by passing it in.

var width = 640, height = 480;

var photo = (function (w, h) {
    return {
        getWidth: function () {
            return w;
        },
        getHeight: function () {
            return h;
        }
    };
})(width, height);

width = 1024;
height = 768;

photo.getWidth(); // returns 640
photo.getHeight(); // returns 480

My earlier article about closures includes another example of using immediately invoked function expressions to save state that you may find enlightening.

I certainly don’t consider myself an expert at JavaScript – unless you’re capable of building something like jQuery or Backbone you cannot call yourself a JavaScript expert, in my humble opinion – but I feel comfortable stating that if you don’t understand how the prototype works (I’m not talking about the JavaScript library) or what a closure is, then you have no business promoting yourself as a good JavaScript developer.

The following is one of the tests that I occasionally use to see whether a candidate has a solid understanding of one of JavaScript’s trickier concepts. What text appears in the alert box?

var width = false,
    height = false;

function init() {
    if (!width || !height) {
        var width = 50;
        height = 25;
    }

    return;

    function height() {}
}

init();
alert(width + ', ' + height);

It may surprise you to know that this code alerts false, false and not 50, 25. It may also surprise you to know that the reason control of the program enters the if block is not because of the false global width and height variables but because of undefined width and height that are local to the init function.

These are the result of a behavior in JavaScript known as hoisting in which all variable and function declarations are moved – “hoisted” – to the top of their scope before the code in that scope is executed.

It might help to see how the JavaScript parser interprets the above code:

var width, height;

function init() {
    var width;
    function height() {}

    if (!width || !height) {
        width = 50;
        height = 25;
    }

    return;
}

width = false;
height = false;

init();
alert(width + ', ' + height);

It’s important to note that the hoisting process moves the declarations to the top of the function rather than the top of the the if block because JavaScript employs function level scope rather than the block level scope used by languages like C++, Java and Ruby – the exception to this rule is the let statement which allows you to declare a block that possesses its own private scope.

Also note that only the variable declaration is hoisted. The assignment expression width = 50 remains within the if block so width starts off with a value of undefined which fulfills the !width portion of the conditional test.

I can’t say personally that I’ve seen any advantage to this hoisting behavior insofar as variables are concerned, but I find the ability to declare functions at the end of a scope particularly useful from a code organization perspective. I think this comes in handy when there’s the expectation that other people will read your code – in my opinion it’s easier to evaluate the code within a function declaration once you already know the context in which it will be executed.

To avoid confusion with variable hoisting, though, just declare all of your variables in a single statement at the top of your scope like so:

var name = 'John Smith',
    age = 28,
    city = 'New York City',
    favoriteFoods = [ 'pizza', 'hamburgers', 'spaghetti and meatballs', 'corn on the cob', 'apple pie' ];

    describe();

function describe() {
    var message = 'Hello! My name is ' + name + ', and I' + "'" + 'm ' + age + ' years old! I live in ' + city + '. My favorite foods are: ',
        i, l;

    for (i = 0, l = favoriteFoods.length; i < l; i++) {         if (i > 0) {
        	message += ', ';
        }
        if (i == l - 1) {
        	message += 'and ';
        }
        message += favoriteFoods[i];
    }
    message += '!';
    alert(message);
}

If I were to declare other functions that contained their own for loops, I could shift the declaration of the i and l variables to the global scope – in the variable declaration that includes name and age – although I probably would just declare them within each function to avoid the performance hit that comes with referencing global variables from within a deeper scope.

The working group responsible for HTML5 eventually caved on requiring specific format support, revising the specification to merely suggest that browser vendors come to an agreement on a codec for the sake of “interoperability.” The result of this was a codec mess with three different formats supported by different sets of browsers:

• Theora video codec and Vorbis audio codec in an Ogg container natively supported by Firefox, Chrome and Opera.
• V8 video codec – another royalty free format unencumbered by any known patents from the same team that developed Theora – and Vorbis in a Matroska-based WebM container natively supported by Chrome and Opera (Internet Explorer 9 will also play WebM formatted video content if the user has installed a V8 codec).
• H.264 video codec – a format heavily encumbered by patents licensed through the MPEG LA group whose membership includes Apple and Microsoft – and AAC – Advanced Audio Coding, the same audio format used by Apple’s touch devices – in an MP4 container natively supported by all Apple hardware (and thus their Safari browsers), Chrome and Internet Explorer 9.

Google to the rescue?

A few short months after Google acquired On2 Technologies, creators of Theora and the VP8 codec, the company released VP8 as open source as part of their effort to promote an HTML5 video format based on an open format unencumbered by patents. This opened the door for Adobe to announce Flash support of the codec and eventually led to Google announcing that they would drop support of the patent-heavy H.264 codec in order to “enable open innovation” and focus on “completely open codec technologies.”

This was, of course, great news to the people behind Firefox and Opera who had been working together to promote the open web with their mutual support of the Theora codec, which Google said they would continue to include in Chrome (Opera also supports V8 in Google’s WebM format).

The only problem was that H.264 was just too entrenched. Apple and Microsoft obviously supported it, being members of the patent licensing organization behind the codec, as did Adobe’s Flash player. More importantly, virtually every available piece of computing hardware from desktops and laptops to smart phones and tablets in recent history has had hardware-based H.264 decoding which meant that it was really a no-brainer for content providers to encode their video with the currently “free” H.264 codec.

Even in the unlikely event that Google didn’t realize this going into their announcement, they certainly learned the lesson quickly: as of today Chrome still supports H.264, and support for the codec in Android was never a question. Not even a conversion of all video content on YouTube to the WebM format is going to make much of a difference since there isn’t any broad hardware support for V8 and Theora (why would there be with the ubiquity of H.264) and content providers are not going to accept the burden of having to encode their video content more than once.

There isn’t much of an upside from a user or business perspective for unified support of an open standards-based video format on the web, and there’s a helluva downside for Google if they switched off H.264 support – the last thing they want is for consumers to experience a failure of YouTube across all smart phones, tablets and interactive televisions.

Google has yet to officially throw in the towel, but Mozilla – arguably an even stauncher opponent of H.264 than Google – has seen the writing on the wall. They all but announced that they would somehow integrate H.264 support into future versions of Firefox, stating that it’s an unfortunate necessity for Mozilla’s mobile initiatives – Firefox on Android and Boot to Gecko - to succeed and for the organization itself to remain relevant.

So where does this leave us now?

Firefox and Opera are the only two major browser clients that do not support H.264. When Mozilla finally releases a version of Firefox that supports the codec, the sole remaining standout of the group will be Opera which as of April 2012 commands a monstrous 1.72% share of the worldwide browser market and 0.63% of the United States market. When that transition occurs there will no longer be any logical reason for anyone whose user base is not made up solely of Opera users to offer web video encoded with Theora or VP8 unless Google defies the popular wisdom and takes the significantly courageous step of removing all H.264 encoded video content from YouTube.

I really don’t see that happening. I once had the optimistic, and probably misguided, view that a big company like Google could and would take that kind of risk just based on principle. Maybe the old Google that eventually tried to make a stand against the Chinese government’s censorship policies and dazzled people with their innovative Google Labs projects would have, but today’s Google is much more pragmatic and realistic than it has been in the past.

We as web developers can at least take a little bit of comfort in knowing that sooner than later we will no longer have to worry about an inconvenient format war. It’s not the ideal outcome, but at least it’s some form of progress that allows us to instead focus all of our energy on creating the coolest possible web applications.

There are a few questions I typically use to get an idea of the candidate’s familiarity with the basics of the language. When I say “basics” I don’t mean whether they know how to declare a variable or find a DOM element by its id attribute, but rather key aspects of the language without intimate knowledge of which one cannot possibly say they are a good JavaScript developer.

For example (and I chose this feature because I already covered it in an earlier post) if you don’t know what an object’s prototype is or how JavaScript’s native inheritance model works then you’re likely a junior JavaScript developer at best. I don’t mean to come off as high and mighty, but, really, there’s a lot more to the language than attaching event handlers.

Speaking of event handlers, let’s take a look at the following bit of code that illustrates two important aspects of JavaScript that can throw some developers used to more traditional functional programming languages for a loop (I’ve personally listened to top tier Java developers curse JavaScript over these concepts).

function initButtons() {
    var body = document.getElementsByTagName("body")[0],
        button;
    for (var i = 0; i < 5; i++) {
        button = document.createElement('button');
        button.addEventListener('click', function (e) {
            alert(i);
        });
        button.appendChild(document.createTextNode('Button ' + i));
        body.appendChild(button);
    }
}

So what happens when we click the buttons generated by the execution of initButtons?

Without fail every candidate I asked this question to responded that we would see an alert box with the number of the button we clicked, and as you can probably guess that isn’t the correct answer since it’s the “obvious” one (and if the answer were really that obvious there wouldn’t be much point to the question).

However, we actually see an alert box with the number 6 no matter which button we click. The reason this happens is because when addEventListener is invoked on button through each iteration of the for loop during the execution of initButtons an entity known as a closure is created.

A closure is, from a simplified perspective, a function that is executed in a scope other than the one in which it was defined while still retaining references to variables that were in its original scope.

When we invoke initButtons, the for loop defines an anonymous function that alerts the value of i. In many programming languages this would mean that the function can only be executed within the scope of initButtons, but JavaScript supports first-class functions meaning that functions are just objects and thus can be passed around. In this case each anonymous function is passed into a button‘s addEventListener method as an argument which assigns it to be executed in a different scope at a later time. The creation of the closure means that even though the scope of this invocation of initButtons has expired by the time the function actually gets executed the function can still access in-scope variables – for instance, the variable i.

So if the event handling function remembers i when it gets called by a click of the button it’s assigned to, shouldn’t the alert box have the appropriate value of i?

Well, no, and the reason for this is because JavaScript has function level scope. Armed with this little tidbit of information it should now be easier to figure out what’s going on.

When the for loop runs, the variable declaration of i occurs once within the scope of initButtons even though it may appear that the variable is being defined during each iteration. Each of those five anonymous functions passed to the addEventListener method is thus referencing the same exact variable i which by the time initButtons is done has the value 5.

So how do we resolve this issue?

The answers I often hear involve using the current value of i in the value of the id or class attribute or inserting it into button's label – essentially some variation of modifying the DOM to “remember” the value.

While these techniques will certainly work, they introduce unnecessary complexity into the code – why crawl the DOM and parse attributes if you don’t need to? – and more importantly miss the whole point of the question which is to understand how JavaScript handles closures and scope.

To that end let’s take a look at a slightly modified version of the above code:

for (var i = 0; i < 5; i++) {
    button = document.createElement('button');
    button.addEventListener( 'click', (function (i) {
        return function (e) {
            alert(i);
        };
    })(i) );
    button.appendChild(document.createTextNode('Button ' + i));
    body.appendChild(button);
}

The big difference here is that we have replaced the simple function object passed into the addEventListener method with an immediately invoked anonymous function expression – essentially a function that is executed as soon as it’s defined.

This new function accepts some value as a local variable i – a new local variable is implicitly defined for each parameter we include in a function declaration – and returns an anonymous function that alerts that value when executed: the variable i in this alert statement refers to the parameter i and not the i created as a variable local to initButtons when the for loop runs.

The outer anonymous function – the one that accepts the parameter i – is wrapped in parentheses to identify it as a function expression – an entity that can actually be executed as opposed to a function declaration which can only define the function as a variable within its parent scope. Thus, in the modified code snippet that outer function is immediately invoked with the current value of i, and the returned function which recognizes that i is passed to the addEventListener method.

The final version of initButtons is as follows:

function initButtons() {
    var body = document.getElementsByTagName("body")[0],
        button;
    for (var i = 0; i < 5; i++) {
        button = document.createElement('button');
        button.addEventListener( 'click', (function (i) {
            return function (e) {
                alert(i);
            };
        })(i) );
        button.appendChild(document.createTextNode('Button ' + i));
        body.appendChild(button);
    }
}

It may be helpful in understanding what’s going on to see initButtons rewritten in the following way:

function initButtons() {
    var body = document.getElementsByTagName("body")[0],
        button,
        callbackGenerator = function (i) {
            return function (e) {
                alert(i);
            };
        };
    for (var i = 0; i < 5; i++) {
        button = document.createElement('button');
        button.addEventListener( 'click', callbackGenerator(i) );
        button.appendChild(document.createTextNode('Button ' + i));
        body.appendChild(button);
    }
}

Now the buttons act the way we expect them to by alerting the number that corresponds to their label.

• Storage size: Cookies max out at around 4KB per domain whereas web storage offers up to 5MB of space in Firefox, Chrome, Safari and Opera and 10MB in Internet Explorer
• Multiple transactions: Complicated management code is necessary to handle more than one transaction on the same site with cookies
• Structure: Web storage provides a better programmatic interface in the form of an associative array model of key-value pairs allowing for more complex data structure and a closer mapping to the popular JSON data format
• Client side only: Local storage doesn’t get transferred to the server with each HTTP request on the domain
• Security: Cookies are vulnerable to exploits such as cross site scripting whereas web storage objects can only access data stored on the same domain

Web Storage comes in two flavors: Session Storage and Local Storage. Session Storage keeps track of all data for a particular page in a particular browser session which can be useful as a failsafe against accidental page reloads or as a mechanism for storing user progress through a single-page web app.

However, I find the Local Storage feature to be much more interesting and useful as it is accessible by any page in a domain and persists through a theoretically infinite number of browser sessions essentially laying the foundation for a client-side database of sorts.

From a JavaScript perspective Local Storage is just another object, not surprisingly named localStorage, with a number of useful and straightforward methods:

• getItem – Retrieve the value of the specified key.
• setItem – Set the value of the specified key.
• removeItem – Remove the entry at the specified key.
• clear – Remove all entries from localStorage.
• length – Retrieve the number of entries in localStorage.
• key – Get the key at the specified index in localStorage.

These are useful for dealing with small amounts of data organized in relatively simple structures, but if we want to interact with larger volumes of data in a more database-like construct we have to roll our own methods to manipulate localStorage.

Creating the database class

The first thing we need to do is create the database class. This will be a global object that can be instantiated so we want to wrap it in a closure that keeps a local reference to the original window object – we do this with an immediately invoked anonymous function expression that includes window as a parameter:

(function ( window, undefined ) {
    var Database = function () {};
}(window);

Each instance of this class will represent a single database within localStorage so the constructor should accept a database name as an argument – this name will be the key for the database in the localStorage object.

The first thing the constructor needs to do is create a local object that will represent the database and initialize it with the data in localStorage. localStorage stores JSON representations of its data so we need to use JSON.parse in order to end up with an actual object, but we invoke this only after we’ve checked that the database already exists in localStorage – why bother wasting resources on a parse call when there’s nothing to parse?

We accomplish this by using the short-circuit behavior of the && conditional in which the expression on the right only gets executed if the expression on the left evaluates to true. We also throw in some code to assign an empty object to database if it turns out that the database doesn’t exist in localStorage.

var Database = function (databaseName) {
    var database = localStorage[databaseName];
    if (!(database && (database = JSON.parse(database)))) {
        database = {};
    }
};

Now we have a database object has been initialized to either the object representation of the JSON from localStorage or an empty object literal. In the latter case we need to take one more step which is to save this new, empty database object to localStorage. In fact saving the current contents of a database object is a necessary piece of functionality that the API should expose so it behooves us to implement a commit method.

Committing data to localStorage is essentially the opposite of retrieving data from localStorage so we need to first serialize the database object (serialization is the process of converting a data structure into a simpler format that can more easily be stored or transmitted) using the JSON.stringify method, and since serialization sounds to me like something that we might be interested in doing with the database object outside of the context of a commit action we should probably separate it into its own method:

this.serialize = function () {
    return JSON.stringify(database);
};

this.commit = function () {
    localStorage[databaseName] = this.serialize();
};

Now that we have the very basic backbone of a database object in place we can focus on inserting and manipulating data which we’ll discuss in the next post.

Everything is an object

Well, not everything.

Operators like + and % aren’t objects.

A literal such as "Howdy" isn’t technically an object, but if a variable str that is assigned the value "Howdy" calls one of the String object’s methods – e.g. charAt - then str is temporarily converted to an instance of String for as long as it takes to execute the function code.

The same goes for numbers like 123 and arrays like [ "a", "b", "c" ].

Any function inherits from the Function object which itself inherits from the Object object. In fact, Object is essentially the mother of all objects since most everything either inherits from Object directly or inherits from String, Number, Array, Boolean, or any of the other “base” objects (Date, Math, RegExp, and Global are in there, too) which themselves all inherit from Object in one glorious circle of life.

Creating objects

There are two ways to create new objects in JavaScript. The first is to define an object literal which is a collection of name-value pairs separated by commas and encased in curly braces.

var pet = {
    name: "Fido",
    species: "dog",
    bark: function () {
        alert("WOOF!");
    }
};

These don’t have an explicit prototype property, but inherit “under the hood” from Object's prototype (Webkit and Mozilla browsers allow you to view an object literal’s prototype via the __proto__ property which is unavailable in Internet Explorer).

The other way to create an object is to define a constructor function that when invoked creates an object.

var Person = function (name) {
    this.name = name;
};
var me = new Person("Nathaniel");

The variable me is assigned an object with only one property - name has the value "Nathaniel" - plus an “under the hood” reference to a prototype object which stores a reference to the constructor as well as a pointer to Object's prototype from which it inherits. As alluded to above the “under the hood” prototype reference is exposed in Webkit and Mozilla browsers as __proto__.

Prototypes

So what happens when you modify Person's prototype?

var Person = function (name) {
    this.name = name;
};
Person.prototype.greet = function () {
    alert("Hello! My name is " + this.name + ".");
};
var me = new Person("Nathaniel");

me itself remains the same with just the one name property, but __proto__ now contains a method greet. Properties and methods defined on a constructor’s prototype are available to all instances by reference, and don’t contribute to instantiation overhead.

And since the greet method is part of the prototype, which is associated to instances by reference, every instance of Person points to the same definition which itself references the name property of the specific instance.

var you = new Person("Joe Sixpack");
var her = new Person("Jennifer");

me.greet(); // Alerts "Hello! My name is Nathaniel."
you.greet(); // Alerts "Hello! My name is Joe Sixpack."
her.greet(); // Alerts "Hello! My name is Jennifer."

That’s all obvious, but it’s important to note that you can also do the following:

Person.prototype.greet = function () {
    alert("Howdy, neighbor!");
};

me.greet(); // Alerts "Howdy, neighbor!"
you.greet(); // Alerts "Howdy, neighbor!"
her.greet(); // Alerts "Howdy, neighbor!"

If you change the value of any member of a constructor’s prototype all instances both existing and future recognize the change, effective immediately.

Setting up inheritance between two objects

Let’s say we want to create a new “class” object Employee that inherits from Person but has its own specialized properties or methods. First things first, let’s create the Employee constructor:

var Employee = function (name, company, title) {
    this.name = name;
    this.company = company;
    this.title = title;
};

In order to set up inheritance between Employee and Person we need to assign Person as the prototype of Employee. There are two ways to do this.

Employee.prototype = new Person();
Employee.prototype.constructor = Employee;

The first line of code establishes that Employee's prototype should essentially be an instance of Person and thus have access to all of Person's prototype members just as any instance would. JavaScript by default assigns Person to the constructor property of Employee's prototype, however, so the second line is needed to reset Employee's constructor to Employee.

There’s a slight problem here, though, that isn’t evident in our specific example involving Person. Person's constructor is a function like any other function capable of running whatever code we feel like including. For example, let’s say Person's constructor looked like this instead of the above example:

var Person = function (name) {
    this.name = name;
    $("body").append('<p>New person added: ' + this.name);
};

This probably isn’t a realistic example, but the point is that the constructor function can run any code including other functions that we may not want to execute if we’re not creating a straight up instance of Person. We want to be able to grab Person's prototype without actually invoking its constructor. To do this we use a second similar technique.

var proxy = function () {};
proxy.prototype = Person.prototype;
Employee.prototype = new proxy();
Employee.prototype.constructor = Employee;

Since we don’t want to invoke Person's constructor we instead use a dummy function as a replacement constructor to instantiate as Employee's prototype. The end result is the same since Employee doesn’t care about anything in Person's constructor – it only wants to know what it should inherit through the prototype.

We still need to reset the constructor property of Employee's prototype which points to Person since it’s inherited from Person.

In either case we end up with an Employee object whose instances have a different set of constructed properties than instances of Person but have access to the greet method from Person's prototype.

Keep in mind, though, that said access to greet is still association by reference so if you change the value of greet in Person's prototype than any instance of Employee will reflect that change going forward.

The prototype chain

As objects inherit from one another they form what is popularly described as a prototype chain along which the JavaScript engine can search for a called property or method.

var e = new Employee("Steve Jobs", "Apple", "CEO");
alert(e.toString()); // Alerts "[object Object]"

When we invoke e.toString JavaScript first looks at the instance itself to see if it has a property or method of that name. Not finding such a member, JavaScript then looks at the instance’s prototype, which refers to Person's prototype, to see if there’s a toString property or method defined there. Since Person's prototype doesn’t include toString, JavaScript then has to go up the prototype chain to the next link, which happens to be the Object object. That prototype does contain a toString method which gets invoked and alerts the string representation of the object.

Only after JavaScript fails to find the property or method in question anywhere on the prototype chain does it give the undefined notification.

Of all the accomplished software engineers I’ve had the privilege of working with only two had even heard of the concept, and one of those guys is pretty close to brilliant having done crazy things like implementing Self in JavaScript!

About a month after I started working at my current place of employment, I was assigned the task of developing a new version of one of our widgets which included a number of “panels” that users would interact with to accomplish their goal. Different panels could have different types of functionality so an obvious starting point was to create a basic “Panel” object from which other types of panels would inherit, and this in fact was one of the project requirements provided to me by the engineering manager.

During the first code review involving yours truly and that manager, it became very clear within moments that he had absolutely no idea what JavaScript prototypes were and had never seen JavaScript’s native inheritance in action. His only experience with “prototype” in the context of JavaScript was with the Prototype framework he used for client-side coding.

This is a software engineer who, while spending most of his time on the server side working with languages like Ruby that use the classical inheritance paradigm, was solely responsible for all of the JavaScript programming for the application with the most complex user interactions!

I tried to explain how prototypal inheritance worked in JavaScript, but I might as well have been speaking a foreign language – he just couldn’t wrap his head around the concept (granted, this was during the span of the one hour during which the code review session took place).

His first reaction was to ask me to consider implementing a more classical inheritance approach in JavaScript in case he or other engineers on the team had to work with my code. This would have sparked a brief debate on the merits of emulating classical inheritance when a perfectly good native inheritance scheme is available, but he was called into an emergency meeting and the subject never came up again since I took over pretty much all major JavaScript development for the company.

While I can understand where my manager was coming from I really didn’t see much point in reinventing the wheel. JavaScript tackles the issue of object inheritance in a clean and easy way with its prototype paradigm, and while a number of JavaScript gurus such as Douglas Crockford, John Resig and Dean Edwards have served up their own solutions as to how to emulate the classical inheritance methodology as seen in Java, C++ and other class-based languages, any one of them will likely tell you that in most scenarios prototypical inheritance is the way to go in JavaScript: you won’t have to invest resources in writing the emulators and any new JavaScript programmer added to the team can hit the ground running with the functionality inherent to the language.