The Principles Of Object-Oriented JavaScript By Nicholas Zakas

Over the weekend, I finished reading The Principles of Object-Oriented JavaScript by the famed Nicholas Zakas. In a relatively short 116 pages (less the index) Zakas takes the reader through the ins-and-outs of using objects in JavaScript. But, don't be confused - this is not a philosophical book about Object-Oriented Programming (OOP) in JavaScript; rather, it is a technical book about how objects are defined, implemented, and consumed in modern JavaScript applications.

Of course, I use the phrase, "modern JavaScript applications," carefully because some of what is discussed in the book is only available in modern browsers that support ECMAScript 5 (ie, Internet Explorer 9+ and just about every other browser). That said, most of the foundational elements in the book (reference types, wrappers, prototypal inheritance, property shadowing, module patterns, etc.) have all been around for as long as I can remember.

For me, this book was an exciting foray into JavaScript. Not only did it shed light on some long-existing features that I had never fully considered (such as Garbage Collection):

JavaScript is a garbage-collected language, so you don't really need to worry about memory allocation when you use reference types. However, it's best to deference objects that you no longer need so that the garbage collector can free up that memory. The best way to do this is to set the object variable to null.... dereferencing objects is especially important in very large applications that use millions of objects. (Page 18).

... it also helped bring me up-to-date on how the JavaScript language is evolving. Even as someone who loves JavaScript, I have to admit that I know very little about the ES5 (ECMAScript 5) aspects of the language. Thankfully, in Object-Oriented JavaScript, Zakas does a deep dive on all of the new "Object" methods.

Beyond ES5, Zakas also does a wonderful job of explaining JavaScript constructors, prototypes, and prototypal inheritance (a.k.a. prototype chaining). For some reason, constructors get a really bad rap in the JavaScript community (despite the fact that they are leveraged heavily inside of many JavaScript libraries and frameworks). I think much of this sentiment stems from a confusion as to how the prototype chain works. As such, I think that clear explanations, like those presented in the book, will help many developers gain a new perspective on how to write their code.

Part of me wishes that the book was a more in-depth look at ECMAScript 5 in its entirety; but, at the same time, I thought the book was a perfect length with great focus. It contained a lot of detail, but not so much that it overwhelmed the reader. Overall, it's definitely a book that I would recommend.

Short link: https://bennadel.com/go/2599

Reader Comments

Ben Nadel Mar 30, 2014 at 7:40 PM

15,674 Comments

Also, for reference, here's a super comprehensive look at the support of ES5 (ECMAScript 5) features in the popular browsers:

http://kangax.github.io/es5-compat-table/

Brought to you by Juriy Zaytsev (aka, "kangax").

Bob Gray Apr 1, 2014 at 9:50 AM

16 Comments

I've recently read Maintainable JavaScript and High Performance JavaScript both by Nicholas Zakas and I thought they were worth reading.

I tend to agree with you on constructors. One argument against constructors is their overloaded nature. All constructor are functions and all functions could be constructors. It is up the consumer to know. Constructors can be invoked without the new operator and in that case they behave differently. This can cause bugs that can be tricky to figure out. Consider:

var checking = new Account("checking"),
	savings = Account("savings");
 
function Account (type) {
	this.type = type;
}

Above checking is an Account instance with a type of checking whereas savings is actually undefined and results in assigning type = "savings" to the global context (or throwing an error if using strict).

Still, I personally think the legibility that the new operator adds to my code is worth the extra responsibility. The cases where a constructor is accidentally invoked without the new operator can also be dealt with by forcing the proper context within the constructor or throwing an error.

function Account (type) {
	if (notAccountInstance(this)) {
		return new Account(type);
	}
	this.type = type;
}
 
function notAccountInstance (context) {
	return !(context instanceof Account);
}

function Account (type) {
	if (notAccountInstance(this)) {
		throw "Account constructor function must be invoked with new operator";
	}
	this.type = type;
}
 
function notAccountInstance (context) {
	return !(context instanceof Account);
}

Personally I like throwing an error because as I said before I prefer to use the new operator.

Ben Nadel Apr 29, 2014 at 8:26 AM

15,674 Comments

@Bob,

Being able to call a constructor with or without the "new" keyword is definitely an interesting behavior. And, I think the first place I remember seeing it allowed in both ways was in the jQuery library. I think they've since changed it (the jQuery function) to call some other init() method... but, I believe they used to perform a context check in the jQuery() method itself; and, if it wasn't called with "new", it would turn around and do it for you.

When I first saw that, it took me a good few minutes of staring at it before I even understood what the heck it was doing :)

The idea of throwing an error if the method was not invoked in the right was is interesting as well. I don't think I've ever seen that done. I'll have to let that one sink in a bit.

Oh my chickens, this post is old!

Hit me up on Twitter if you want to discuss it further.