Book review: “JavaScript: The Good Parts” by Crockford
Date : 2008 07 29 Category : Tech & Development
Ajaxian
I heart David Flanagan. I'm making my way through "The Ruby Programming Language" this summer. Its exhaustiveness really satisfies. But a decade ago, my programming Bible was Flanagan's "JavaScript: The Definitive Guide". As I transitioned from a career in content to a career in code, "the Rhino book" taught me everything I needed to know about object-oriented JavaScript, DOM scripting and the other building blocks of today's Ajax landscape. I've bought a hard copy of each of the book's five editions. It remained, until recently, the only JavaScript book I'd recommend.
That all changed with the recent publication of JavaScript: The Good Parts by Yahoo's Douglas Crockford. Crockford probably needs no introduction. His incisive website and frequent blog posts have championed JavaScript's power and potential while calling out its drawbacks and frequent misuse. Now, with "JavaScript: The Good Parts," he has managed to provide a reference as useful for JavaScript pros as it is for novices. Part language primer, part apologia and part critique, Crockford's book draws from and extends many of his long-gestating themes about how to use JavaScript - and how not to use it.
The author's premise is so simple and intuitive that it sounds like rubbish until you suddenly realize that this is how all programming languages should be taught:
When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. ...
Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes.
Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?