Burningbird's RealTech

A List Apart has a timely article titled Understanding Progressive Enhancement discussing the perceptual differences between graceful degradation and progressive enhancement. I enjoyed seeing Steve Champeon's idea given new light. Additionally, now is as good a time as any to have a go at these topics, with the many new enhancements being added to today's browsers, while antiques still cutter cyberspace. I could have done without the cloyingly cute M & M analogy in the article, but that's probably my inner Cranky Woman having a go this AM.

I've written about graceful degradation, previously. Graceful degradation means applying modern technology but ensuring the application doesn't negatively effect those viewing a web site with an Antique (remaining nameless). However, contrary to the ALA author's statement of Under this paradigm, older browsers are expected to have a poor, but passable experience, graceful degradation is just that: gracefully degrading, meaning that though the person using the Antique doesn't get all the bells or whistles, their experience at the site is more than "poor but passable".

Progressive enhancement, on the other hand, begins with the content, rather than the technology; ensuring that the markup used to organize the content is semantically correct and valid. Then, and only then, the web site developer progresses to the use of CSS and JavaScript, both to annotate and enhance the content. That's been the primary difference between the two approaches: graceful degradation tends to focus on technology, first, while progressive enhancement focuses on content, first.

My editor at O'Reilly sent me a copy of Douglas Crockford's JavaScript: The Good Parts, which I found to be both interesting and useful. The volume is slim, 153 pages in all, but packed full of information about JavaScript—the good parts and the bad.

I found myself nodding more than once, raising my eyebrow a couple of times, and chuckling a time or two, especially when reading about the equality operators, those "evil twins" of JavaScript, according to Crockford.

The book is not intended for neophyte developers, or even those new to JavaScript. It does, however, give you insight into the mind of a very experienced JavaScript developer. Such insight can provide the information necessary to take you from being familiar with JavaScript to being experienced with JavaScript. In particular, the book's fourth chapter on Functions is, by itself, worth the price of the book.

Crockford writes clearly and without pretension, which I found refreshing. His aim is to clarify, but without pandering. He doesn't hold you by the hand, and don't expect him to explain every last bit of the subjects introduced. However, reading through his material is a nice confirmation as to whether your understanding of JavaScript is comprehensive, or if you're missing out on some of the bits. I particularly liked his chapter on regular expressions, because I suck at regular expressions.

You'll also be served a hefty dose of Crockford's opinions on the JavaScript language, which is no bad thing. I didn't necessarily agree with all of his opinions, such as avoiding the use of new, but I liked reading the opinions because they help me question my own use of the JavaScript language: is this necessary? Could this be improved? Why am I doing this?

I don't usually have opinions, good or bad, about components of a language. I either like the language, and learn to adapt to the awkward pieces; or I don't like the language at all. I like JavaScript, so I tend to like all of JavaScript, even the grungy parts. If there's one thing I consider to be a "bad" part of JavaScript, it is the experts in JavaScript who tell us not to do this or that, but either give no reason for their opinion, or the reason they give borders on the obtuse and cryptic—assuming that we, of course, know exactly what they're talking about (if we're worth anything as programmers, goes the implication).

Reading Crockford laying out his opinion as to what he considers "bad" in JavaScript, and why, in clear, unambiguous terms—with examples—is like a breath of fresh air. His doing so is also worth the price of the book (leaving me to wonder whether I should, in all fairness, pay twice). I can only hope other experts, in whatever language, follow his lead.

My only quibble with the book is one paragraph in the chapter on Objects, and that's because I'm still puzzled by what I read. Crockford writes:

The simple types of JavaScript are numbers, strings, booleans (true and false), null, and undefined. All other values are objects. Numbers, strings, and booleans are object-like in that they have methods, but they are immutable. Objects in JavaScript are mutable keyed collections.

My understanding of immutable objects is that these are objects, not some form of pseudo-object, or second class object. If I had been a tech reviewer for this book, I would have asked for additional clarification of this paragraph in the text.

Other than this relatively minor quibble, though, I really enjoyed this book. It is a nice read, and invaluable for any JavaScript developer.