« Back to home

JavaScript: The Good Parts

I remember back in the 1980s paying something like £40 for a copy of Kernighan and Ritchie’s original book on “The C Programming Language”. An outrageous amount for a book which was a little over 200 pages, I thought.

However, during the 1990s, something happened to books about computer programming. Like the fast food junkies of our nations, they started to get bigger and bigger, with the essential meat surrounded by more and more extraneous fat. These days, most computer books are Doorstop Books. They’re at least 4cm thick, and make a great tool for propping open a door or killing a cockroach. As a tool for learning a programming language, however, I find them not so good. I’ve come to value conciseness in technical literature. I have things to do, and a bloated book too often stands between me and my task.

I’m sure there are people who work better with something like The Complete Book of C Programming, a mammoth tome with more than 1000 pages. But K&R is still out there getting rave reviews, gently updated for ANSI C, and a quarter of the length — because when you get right down to it, ANSI C just isn’t that complicated of a language. (And for the bits that are that complicated, you need the actual standard.)

Bloat is even more apparent if you look at books on UML. When you come right down to it, UML is just a bunch of conventions for how to draw diagrams that represent how pieces of software behave (or should behave) — glorified flowcharts. UML does not require 984 pages to explain. If you’re a programmer, you can get at least 90% of what you need to know about UML from Fowler’s UML Distilled, a mere 208 pages.

O’Reilly’s publishing genius has been that they generally find a happy medium between conciseness and bloat. They publish tech books which are concise enough to be useful, but large enough to look reassuringly definitive. Some of their books are excellent, and very few of them are truly bad. However, their …in a Nutshell series has started to show worrying signs of drift, with Java in a Nutshell becoming bloated with discussions of frameworks and reproductions of the API documentation, rather than sticking to its subject matter.

So I was a little skeptical of their new book, JavaScript: The Good Parts. I gave it some very careful perusal in the bookstore before buying. But I’m happy to say that it’s as good as the Amazon reviews suggest. My one-line blurb would be: Finally, a book on JavaScript for computer scientists.

JavaScript is a much misunderstood language — deliberately so. In case you’re one of the few people who hasn’t gotten the message yet, it has absolutely nothing to do with Java. The language was originally called LiveScript, but was renamed by Netscape as a cynical marketing ploy. It may seem hard to believe now, but at the time Java was seen as really cool, the language to be learning and using. Now, ironically, the association with Java probably hurts JavaScript more than anything else.

Did you know that JavaScript is a proper object-oriented programming language with exception handling? That it supports functional programming — including anonymous functions, functions as first class objects, and currying? I didn’t for the longest time, because all I ever saw in actual use was a clunky scripting language that looked like C.

What Douglas Crockford has done in his book is set out a clean subset of JavaScript, and show how to construct essential features of a good programming language (such as modules and limited scope variables) from the features supplied by the language. Alongside this is discussion of the bad (or in some cases, awful) bits of JavaScript, the parts to avoid if you want to write clean, maintainable code.

Make no mistake, though, this is a book for software engineers. The chapter on functions was heavy going, doubtless because I haven’t done any real functional programming in years. I found myself re-reading sections multiple times, as the squirrel of recollection scurried around in the dusty attic of my memory.

Overall, though, I’d say that this book provides pretty much everything the experienced software engineer needs to learn JavaScript, the language, and start coding in it. Understanding other people’s JavaScript might be more of a challenge, and the DOM is a whole separate minefield.

In fact, I’d love to see the obvious next step: DOM: The Good Parts, a book which describes only the standard parts of the DOM, and then flags the bits that don’t work on common browsers.

And then perhaps someone who likes a real challenge can attempt to write C++: The Good Parts — with Appendices A thru E being the bad parts, the awful parts, the abysmal parts, the parts even worse than that, and the parts that make you wonder what Stroustrup was smoking.