d’bug shares tips, tricks, and advice with Web development professionals

I wish I could say that was an exaggeration, but after a lot of thought, I believe that is the current state of the language. Some might consider it progress to push JavaScript that much closer to a pure object-oriented (OO) language, but I think it continues to bring with it false expectations. There are too many other limitations (which is not necessarily a bad thing), and a classical inheritance structure only serves to confuse beginners who are unable to learn JavaScript responsibly.

That is not to say there are some slick implementations by talented programmers, and they all do a fair job, including John Resig, Dean Edwards and Sam Stephenson through Prototype. I am afraid though, that other developers misunderstand the purpose behind these design choices, and fail to realize they are just that — a personal desire for a more classical design. You can achieve much, if not all of the same functionality using JavaScript’s built-in prototype inheritance model. Douglas Crockford appears to hold the same view,

I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake.

The root of the problem

I believe the root of the problem is that most beginners who want to learn JavaScript’s prototype inheritance model have never had a background in an OO language. This foundation helps them to understand key OO concepts, but more importantly it helps them to distinguish the difference between a JavaScript prototype object and a class “blueprint”.

Instead, a compensation has been made by experienced programmers to try and teach OO programming through the JavaScript language itself, which only adds to the problem. A prototype inheritance model is better explained as it should be, without too direct a correlation to the classical inheritance structure.

In JavaScript, behavior between objects is shared by cloning an existing object that acts as a prototype for a new object. The focus is primarily on function and behavior, which can be passed from object to object. However, in classical inheritance the focus is primarily on archetypal patterns. Emphasis is put on the parent-child relationship, and hierarchies can be strictly enforced.

Changing how you think about objects

I think the best place to begin teaching prototypal JavaScript, is to change how we describe objects in the browser environment. Instead of treating them like a class, we should treat them like a prototype.

If you have ever read a tutorial on OO programming with JavaScript, it usually begins by describing objects in the real world, such as a person or an automobile. Even abstract objects are used, like a shape or a building. Those illustrations will almost never translate to the client-side. That is not to say that they are not relevant, but they will fail to aptly represent the majority of the objects that will really exist in a client-side program, and that are accessible through a prototype.

So if objects in the browser are not typically people, or circles, or a Toyota Civic, then what objects can you expect to create? After using JavaScript libraries for some time, I can tell you that jQuery and Prototype have both done a good job of identifying the vast majority. I would consider these to be virtual objects, with no physical representation, which is often what you encounter in the OO world. You get things like TaxCalculator, ShoppingCart, Promotion or SearchResults.

If I had to organize these objects, I would put them into the following categories, which you will see represents the major components of the aforementioned libraries:

• Ajax
• Animation
• Browser
• CSS
• DOM
• Event

There is of course the need for one more, which would be Application. Whatever custom prototype objects that you need to run your application would fall under this category. It is a big bucket, but unless you find yourself developing intense client-side applications that mimic an operating system (or you are Google), then this will suffice. Depending on your application needs, all of the categories listed could actually fit in Application, much like the jQuery namespace.

Starting over

The question then becomes, where do you go if you want to learn the nuances of prototype inheritance from scratch without too many parallels drawn to classical inheritance? There is no easy answer. I have come across some great tutorials, and books, that do a sufficient job explaining what it is, but do a poor job with the execution. Unfortunately, researching the prototype property brings up a great deal of material on the Prototype library, making the situation worse.

If you have links or resources that you would like to include that you think do a better job than most, please feel free to pass them along. Here are just two to get you started in the meantime:

• Using Prototype Property in JavaScript
• The prototype object of JavaScript