Javascript: The Good Parts By Douglas Crockford
Posted May 18, 2011 at 10:31 AM by Ben Nadel
On my flights to and from cf.Objective(), I finally read Javascript: The Good Parts by Douglas Crockford. I went into this book with extremely high expectations. I've been hearing about "The Good Parts" for years. Written by the famous Douglas "Papa" Crockford, this book has been recommended to me countless times by many developers. With so much hype, I half-expected my brain to start bleeding from its excellence. However, having just read it, I can tell you that this book is not magical and it didn't cause my head to explode. Rather, it is just a thought-provoking, well written, thorough exploration of the Javascript language.
| | | | ||
| |  | | ||
| | | |
From a technical standpoint, Crockford does a great job. He really goes through the important parts of the Javacript language and explains how things work. One repeated pattern that I found to be hugely effective was when Crockford demonstrated how to mimic a particular native function using other native functions. For example, while he documented the Array.unshift() method, he also pointed out that the same functionality could be achieved using the Array.splice() method. In doing so, not only did he instill a solid understanding of the native functionality, he really got the reader to think beyond the method signatures - he got the reader to think about the problems being solved.
Another part of the book that I really enjoyed was his outlining of the concepts that went into JSLint - his Javascript code quality tool. While I didn't necessarily agree with all of his finer points (I love the ++ operator), it was great to see someone clearly articulate why certain approaches to code organization and structure can be problematic. Looking at code in this way can help you become more cognizant of the code you write; and, the more connected you are to your code, the better its going to end up being.
The one part of the book that did leave me wanting more was his exploration of object inheritance. In today's world, it seems almost "hip" to talk about how "broken" Javascript is as a language. As such, I was hoping that Crockford would swoop in and settle the issue, shedding light on "the way" we should build object chains in a Javascript context. And, while I do like the way his examples progressed through the various forms of object-based extension, I can't say that I came away with any revelations.
Currently, I build my object chains using the "new" keyword in conjunction with Constructor functions. This is how I was taught to write Javascript; and, it seems very natural. There's nothing about this approach that feels "broken" to me. From what I undersand, the "new" keyword uses the Prototype chain in the way that it was designed to be used. I didn't see anything in The Good Parts that made me want to change the way I am doing things. None of the other approaches to object-based inheritance seem to address problems that I am experiencing.
Despite my disagreement with certain inheritance view points, I really enjoyed this book. In fact, seeing so many alternate approaches really got me to think about how objects are wired together in Javascript. Actually, if I had to pick my favorite aspect of the book, it would be the fact that it really got me to think deeply about the language itself. Part technical manual, part soap box, part philosophy, "Javascript: The Good Parts" will make you a better developer because it will make you a better thinker.
Reader Comments
And yet you still refuse to capitalize the "S" in JavaScript...
@Tony,
Old habits die hard. I think maybe I was dropped on my head as a child :)
He doesn't like "with" either. Considers it harmful. And his minifier doesn't substitute shorter variable names. And his JSLint wants a ; after the } if you use "= function(){}" syntax. I guess you can say he's motivated by an abundance of caution, which isn't such a terrible thing.
Can't fault his understanding of the language. Before this book, he was the one who got me to think of the prototype property as being like the "super" keyword of object-to-object inheritance, and all of a sudden the term "prototypal inheritance" made sense to me. Walking the prototype chain too. Why hasOwnProperty is important. The Object.create() that's now a part of ECMAScript. All of that. If you're going to use prototypal inheritance, why not use the hell out of it, use it for all it's worth?
And I agree, "new FunctionName()" is fine. So is "{name:value,...}" syntax. Freedom of expression!
@Tony: Yipes! If you think that's bad... A fellow developer I know, refers to JavaScript as Java all the time. You are quite right though, Ben, get it right :)
@WebManWalking,
I definitely hope I don't come across as disliking the {...} object creation approach. I love object literals. I just don't use them when I am creating objects that are *intended* to be extended. I think it is all a matter of context.
@Chris,
I'm sure it will sink in eventually :)
@Ben: No, you didn't come across as disliking object literals.
At the beginning of Chapter 4, Functions, Crockford notes that objects defined by literals are linked to Object.prototype, thereby guaranteeing that they inherit no properties. But then, further down in the chapter ("Augmenting Types"), he defined Function.prototype.method as a clean way to attach a new method to any object. Example,
- String.method("trim", function () {
- return this.replace(/^\s+|\s+$/g, '');
- });
I wrote to ask him why he didn't define it as Object.prototype.method.
He wrote back, simply: "Object is a Function."
WHAT!??? WHAT!!!???
So I did what you do. I wrote a little test program to see what happens.
- alert("{}.constructor = " + {}.constructor);
I'll be damned. {} is the same as new Object(), which implies that Object is a Function.
I'm going to need more beer to figure this out: What came first, the Object or the Function?
And, get THIS:
- alert({}.hasOwnProperty('constructor')); // false!!
- alert('constructor' in {}); // true!!
And all 3 alerts on {}, above and in the previous post, gave the exact same results in Firefox 4, Google Chrome 12, MSIE 7, Opera 11 and Safari 5.
I've been coding in JavaScript since it was case insensitive, believe it or not, prior to the "Atlas" release of Netscape. But it never fails to blow my mind from time to time.
Try these:
- alert(Object.constructor);
- alert(Function.constructor);
I may have to change my handle to WebManGawking.
@WebManWalking,
Yo, the method() thing, for me, was a huge mind twister. It's funny - it's meant to make things simpler; but, for me, it made things more complex because it took me a while to wire it all in my head.
For those of you who have not read the book, the code Steve is referring to is:
- Function.prototype.method = function( name, handler ){
- this.prototype[ name ] = handler;
- return( this );
- };
The part of this that always take me so long to deconstruct comes back to the thing we said above: Object is a function.
And, so is Array(), String(), Function(), etc.. All constructor functions are both objects and functions.
So, when you add something to the prototype of Function, you are adding it, at runtime, to all *instances* of functions (which includes Object, Arrays, String, etc.).
This abstraction always trips me up. I'm used to seeing "Something.prototype.method", that having the prototype part hidden away from me is confusing :)
I agree it's well written and he expresses his thoughts. It came with too any opinions instead of insights into the language. I liked the train diagrams, but I didn't like his opinions on code structure. Every if should have a block {}, but i++ is much more readable than i = i + 1.
The nail in the coffin was I got a free copy of the book delivered to me on Christmas eve to my apartment when I wasn't there. Because of that, I also got robbed! I gave both copies of the book, it doesn't hold it's weight compared to great books like JS Design Patterns and Zakas's books.
@Drew: Yeah, funny that Zakas and Crockford both work at Yahoo. His explanation of how "with" works proves that "with" is a be-careful thing, not a bad thing.
http://www.youtube.com/watch?v=mHtdZgou0qU
@WebManWalking,
Yeah with is interesting and I must say I rarely use it, because of fear over it's downsides. However, it is used heavily in Firebug.
Zakas and Crockford also defer on JSLint, Zakas seems to given up the fight for Lint and switched to using JSHint: https://github.com/jshint/jshint/issues/18#comment_804824.
@Drew: Cool. Thanks for the URL.
@Ben: Right after I posted my previous reply about Zakas, this site started returning "An error occurred" (or something like that) on every page request. Just FYI in case you didn't know. (It was after hours.) You might see something in the logs.
As I've been watching his video and reading his book, I started putting together a single web page that categorizes every "thing" that I've been learning about JavaScript. There are columns labelled "Category, Rsvd, Use, Thing, Example, Note".
"Rsvd" is for whether it's a reserved word or not.
"Use" has several values, like "Intro, Yes (normal use), Adv, No (Recommended you not use), and NO (DO NOT USE - EVER)".
I've got 2 "nos" in there in homage to JavaScript's case sensitivity.
I'm having to go back and reread a lot because I'm not as smart as most of you guys, so the page is definitely in a state of flux right now.
http://www.cfmzengarden.com/jsZenGarden/000/000.cfm
@Drew,
Sorry to hear about your apartment woes! That sucks :( As far as "opinions" go, the one thing that I am getting a bit tired of in general is people hating on Javascript. Maybe I've not been building big enough things or what not; but, I just spend my time thinking about how broken it is. People seem fixated on it.
@WebManWalking,
You were posting at 4AM EST. That's when the squirrels come and start chewing through wires!!
@Phillip,
Dang! That looks really cool!
Ben,
I was really encouraged by you saying "Dang! That looks really cool!", so I worked on what I call "jQuery Matrix" all day yesterday. Check it out and tell me what you think.
http://www.cfmzengarden.com/jQueryMatrix/
It still needs some love, but it may be a while before I get back to changing it.
@Phillip,
That's pretty awesome. I just spend like 5 minutes scanning through random methods. I just learned that .val() will return an array on multi-select values. I did not know that. Slick stuff :D
I'm trying to learn JavaScript partly thru the use of "JavaScript: The Definitive Guide". So far so good but I am bogged down with the concept of enumerability in reference to strings. Pgs. 125 & 126 show examples where testing an object returns false because "toString" is not enumerable. If a an array can be a string and an array is enumerable why can't "toString" be considered enumerable?
