Prototypal versus Pseudo Classical – The Debate


In JavaScript circles there can be no greater contentious debate than the one revolving around prototypal versus pseudo classical inheritance and cantankerous discussions about politics can appear civil when compared. Proponents on either side of the aisle are quick to deride those whose views differ from their own. The ‘purists’ as I call them are quick to point out that there are no classes in JavaScript and that objects beget objects, period! On the other hand, ‘classical style’ developers (those who very likely came to JavaScript after having used a traditional class based programming language, such as C++, Java, C#, et al.) are quick to point out that JavaScript actually does support object creation via its new operator conjoined with constructor functions which provides the semantic sugar needed to mimic traditional class- based languages.

Part of the problem, I believe, lies in the terms either side use to bolster their own views. For instance, when speaking on the subject proponents on both sides of the debate often refer to ‘classical inheritance’ instead of the using the correct term which is ‘pseudo classical inheritance’. In this regard I believe even Douglas Crockford refers to the conjoined use of the new operator with a constructor function as pseudo classical inheritance and not as classical inheritance. Inclusion of the word pseudo here dramatically changes the meaning and obviates any confustion that it isn’t really classical at all but rather is a fake or pretending form of classical inheritance.

Furthering the confusion is the often misquoting of Douglas Crockford on this subject. While Mr. Crockford classifies the conjoined use of the new operator with a constructor function as one of JavaScript’s bad parts, it is important to understand his motivation for that. JavaScript at this time (here I am referring to Ecmascript 5) cannot prevent you from calling a constructor function without the use of the new operator. This can result in polluting the global name space. Knowing this then should reminds us all that we should be using static parsers such as JSLint and JSHint and declaring ‘use static’ in all our functions.

So what, then, is the real issue here and why do I really not care that much about it? There are certain developers who are passionately opinionated on this subject and they feel they must try to coerce everyone into accepting their own opinions as the gospel and heaven help you or anyone who disagrees with them. In development as in life we can not escape the fact that there will always be those who want to draw us in to their own views of correctness, so beware.

JavaScript is an incredibly expressive and dynamic language. It allows us to create objects in many different ways and I believe that is one of JavaScript’s greatest strengths. It is therefore a testament to the versatility of JavaScript that the language allows those who favor one form of object creation over the other to use their favored approach.

When coding JavaScript I use both pseudo and prototypal approaches to creating objects though I admittedly favor shallow object hierarchies and composition(*1) over deeply rooted inheritance. Mr. Crockford seems to favor this technique as well. In its essence, composition allows avoiding deeply rooted object hierarchies while allowing for the ability to create semantically rich and expressive objects. JavaScript makes implementing composition incredibly easy and I will cover composition in depth in a future article.

The best advice I can give to budding JavaScript developers is the following:

  • Avoid getting caught up in philosophical debates. That isn’t to say you shouldn’t have opinions. Just don’t get caught up in them. Instead focus on perfecting your craft and code, code, code.
  • Learn how to create objects using all the varied ways that JavaScript supports — prototypal, pseudo classical and composition.
  • Understand their good and bad parts — they have both.
  • Use linting all the time. Today there is no excuse for not using it. If your editor or IDE doesn’t support real time linting then dump it and find one that does.
  • Use strict. Unless you are dealing with legacy code any new code you develop should include ‘use strict’ in every function.
  • Last but not least, let your own educated opinions guide you – emphasis on ‘educated’.

(*1) To be more precise, I often create objects combining prototypal inheritance, the modular pattern and composition.



One thought on “Prototypal versus Pseudo Classical – The Debate

  1. Anonymous

    Greetings from California! I’m bored to death at work so I decided to check out your site on my iphone during lunch break. I enjoy the knowledge you provide here and can’t wait to take a look when I get home. I’m surprised at how quick your blog loaded on my phone .. I’m not even using WIFI, just 3G .. Anyways, awesome blog!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s