Book review: JavaScript: The Good Parts

As I’m sure you know, I have a very strong interest in JavaScript, and what better way to try and feed that, than to read a brand new book by Douglas Crockford entitled JavaScript: The Good Parts!

Being a fan and being inspired

When I first started reading about Douglas’ mindset and ideas, and seeing him doing a live presentation, he immediately felt very right on track. Extremely experienced, almost to the extent that some find him cynical or bitter, but if people just read/listened to what he says more thoroughly, they’d find out that he tears something down to able to become constructive and truly inspiring at the end.

Some of his work has fundamentally changed the way I look at JavaScript, and it has definitely made me become a better JavaScript developer. His most influential work is, I’d say:

The book

Basically, this book is about the conclusions he has come to over years in relation to write the best-performing, most-easy to read and maintain, and last, but not least, the most stable JavaScript code. It mainly deals what he finds to be the best parts, but what I’d say is most gratifying is when he, especially in the appendixes, brings up the bad parts and why they are indeed bad (kind of like why IE sucks; most people know it, but it’s good to bring out some hard facts from time to time).

Douglas begins each chapter with a Shakespeare quote; perhaps pretentious to some, but I don’t mind. Either way, this is totally compensated for with some great Lost references in the code samples! Also, it feels a bit ironic about praising JavaScript and at the same time only being able to produce a book containing of merely 145 pages talking about what’s good with it. πŸ™‚

The Chapters

The book consists of 10 chapters and 5 appendixes:

  • Chapter 1. Good Parts
  • Chapter 2. Grammar
  • Chapter 3. Objects
  • Chapter 4. Functions
  • Chapter 5. Inheritance
  • Chapter 6. Arrays
  • Chapter 7. Regular Expressions
  • Chapter 8. Methods
  • Chapter 9. Style
  • Chapter 10. Beautiful Features
  • Appendix A. Awful Parts
  • Appendix B. Bad Parts
  • Appendix C. JSLint
  • Appendix D. Syntax Diagrams
  • Appendix E. JSON

My take

Overall I think it’s a good book, but I have to say that I’m a bit disappointed that there was no real eye-opener; not anything like Dan Webb’s chapter in The Art & Science of JavaScript. Most likely, however, this is due to me having adapted the ideas and mindsets described above from Mr. Crockford even before, and as anyone who has used JSLint and really cared to find out why those warnings showed up, I’ve learned from it and has gotten better.

So, to anyone being a seasoned JavaScript developer and already agreeing with advice and approaches such as those offered by JSLint and the JavaScript Module Pattern, this book will maybe fill in some blanks, but I’m sure you know most of it already.

However, to anyone being an experienced developer, but in other languages than JavaScript, this is a fantastic book which explains how JavaScript really works, and how you can see the object, inheritance and prototype model in JavaScript as something good, instead of an obstacle.

And, for anyone who has just started out with JavaScript, I’d say that JavaScript: The Definitive Guide, Fifth Edition is a mandatory read, and after about six months, you should read JavaScript: The Good Parts as a perfect complement to that book.

7 Comments

  • Remy Sharp says:

    I bought this on pre-order and received it a couple of weeks ago. I've not read it – but I did suspect it was going to be mostly things I already knew.

    I think it was more to hammer home some of Crockford's approaches. Cheers for the review, it's encouraged me to get back to the book!

  • "Lost" references in the code samples? I totally need to read this book. πŸ™‚

  • JSlint is not perfect, and there are a lot of scripts that fail in JSlint, but are written truly correctly.

    As I think (and said I don’t know how many times) JSlint is a “developer mood“, but not the indisputable correct way to write JavaScript code.

    However, big Douglas is a great JS developer, and part of a great JavaScript team, but sometime their blog, as probably this book (reading your comment), are too much self-concerned, while Yahoo library is not “the perfect one“, and sometime it is not better than others (performances, elegance, features).

    My cent, for a book that I’ve not read, yet πŸ™‚

  • Crockford was the one that opened my eyes for Javascript, and it is now my favourite language beside Common Lisp. So, the little Javascripter is my favourit Crockford writings.

    But the module pattern? What does that say about your personality: marking private methods with underscore in my perfect code is not good enough, I must prevent other coders from ever ever being able to touch my private parts. I must remove the theoretical possibility of ever touching them, for the benefit of inferior coders that don’t understand the concept of private. Not even when the nuclear power plant is about to melt down should you do a quick fix with my perfect private code. It feels more like C++ or ADA than a good coding practice for a modern dynamical language.

  • Robert Nyman says:

    Remy,

    Good that I got you back on track then! πŸ™‚

    Jonathan,

    Ha ha! Yep! πŸ™‚

    Andrea,

    Well, there are some things that can be discussed, and absolutely, it's based on his conclusions. But I'd say about this book at least, is that he doesn't bring Yahoo or YUI forward in any way, and it is indeed written in an very general fashion.

    Henrik,

    Glad that you've been inspired by Douglas!

    First and foremost, I find it most important for everyone in the development team to agree how they should write good, and, naturally, feel good about it. Personally, I like the module pattern because it makes for a clear separation in the code about what's private and what's public.

    When developing a web site shared with a lot of other web developers, bringing in code from an external source you can't control or offer your code as a public API, I think it's a good approach to avoid that key aspects in your objects aren't overwritten.

    PS. I really like the idea of stix.to DS.

  • Richard Cornford says:

    Why have you listed "The JavaScript Module Pattern" among Douglas Crockford's "most influential work" when it was not his creation and he did not participate in its development (so it is in no sense "his work")? A better candidate for inclusion in that list would be his closure-based technique for emulating private instance members on javascript objects. Particularly as that is one of the influences behind the module pattern itself (and so a very good candidate for the label "influential"). But the module pattern is two steps beyond the emulating private instance members, and Douglas Crockford did not take those steps.

  • Robert Nyman says:

    Richard,

    Since it was Douglas I learned it from Douglas in person, when he explained the inner workings and thoughts behind it. He was promoting it and thought that most people should start using it.

    I'm not really claiming that he invented it, or have no input from others with working with it, but rather just that it was him I learned it from.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.