found drama

Maintainable JavaScript by Nicholas Zakas (O’Reilly 2012) is a short-and-sweet little text on (as the cover says) “writing readable code”. And by “readable code”, Zakas means “code that other developers not named [YOUR NAME] will be able to read and comprehend of and ultimately maintain”. It goes beyond maintainable and readable code though–Zakas takes us on a tour of how to deliver high-quality JavaScript that is testable and maximally performant in production. If you look at Zakas’ catalog, this subject is right in his wheelhouse, and the book reads like either a sequel to his 2010 High Performance JavaScript or else as a lengthy appendix ¹ to his 2012 Professional JavaScript for Web Developers (3rd edition). ² It’s an opinionated book about formatting style, about programming conventions, and about ways of helping you (and your team) write code that is a lot less likely to blow up on you down the line.

Right off the bat: the target audience for this book is not advanced JavaScript developers. If you are an advanced JavaScript developer (or even many mid-level JS devs) then these are concepts that you are already familiar with. You’ve already dabbled in a style guide. You already know to minimize global variables. You already know to use feature detection. And there’s a good chance you’re at least linting, if not testing, if not doing both of those things automatically as part of your build. If that sounds like you, then you might want to take a pass. But before you do, give the table of contents a second glance. ³

So who is it for? It’s for novice and intermediate level JavaScript developers that want to get a better sense of what “readable” and “maintainable” code looks like. It’s for folks that are plowing through the other “slim” JavaScript books in the O’Reilly catalog. ⁴ It’s for technical managers who don’t have a JavaScript background. It’s for folks that want to start a book club for front-end devs and have spirited debates about ASI and how many spaces to indent when an expression continues on the next line.

As I worked through Part I (“Style Guidelines”), my initial impression was that Zakas was writing a how-to for writing JavaScript style guides. We have 44 pages of in-depth discussion on where to put curly braces, how many blank lines to use (and where), and what a proper comment looks like. Esoteric rationales to inform what (on the surface) seem like so much pedestrian banalia. (“Who cares what I name my local variables?”) But by the end, there is a well-reasoned case made for all of the recommendations that appear in Appendix A.

Where the book becomes more interesting is in Parts II (“Programming Practices”) and III (“Automation”). Again: the chapters that comprise Part II are going to seem like review for many seasoned JS devs: keep your JS and your mark-up loosely coupled; avoid global variables; keep configuration data separate from business logic; use feature detection instead of browser detection. As much of these may seem like review, ⁵ don’t get cocky and skim it, either–there are some gems in there. (In particular I’m thinking of the chapter on Event Handling that spawned this interesting post by Ben Nadel.)

The chapters in the Automation section were my favorites. Zakas builds up a solid Ant-based ⁶ build system over the course of 7 chapters that includes validation and linting, file concatenation and gzipping, minification, documentation, and automated testing. As I’ve become highly interested in the build process, I was riveted by these chapters. Zakas at least touched on every topic in the automation/build topic that I would have wanted to see. But that being said: the operative phrase was “touched on”–I would have loved to see more on this subject. He provides a lot of excellent starter material, and Appendix B is a rich list of other jumping-off points, but it also seemed… shallow? Like he was just scratching the surface? This seemed especially true of the chapters on documentation ⁷ and testing. ^{8 9}

All in all? I would strongly recommend this to folks that are new (or “new-ish”) to JavaScript, but only a mild nudge to seasoned folks.

• Buy it on Amazon.com; or
• get the book directly from O’Reilly.

Disclosure: I received an electronic copy of this book from the publisher in exchange for writing this review.

1. And by “lengthy appendix”, I mean “expanded version of Chapter 24”.[↩]
2. Which, I’d like to add: is still my all-time-favorite JavaScript book. (Second edition reviewed here.)[↩]
3. If nothing else, you’ll feel really validated seeing that “you were right” about all those little details.[↩]
4. And by “the slim JavaScript books”, I mean: Crockford’s JavaScript: The Good Parts, Stefanov’s JavaScript Patterns (previously reviewed here), and Zakas’ High Performance JavaScript (previously reviewed here).[↩]
5. Especially if you’ve been keeping up with Zakas’ blog posts. “Don’t Modify Objects You Don’t Own”, anyone?[↩]
6. Honestly though, my first thought was: “Really? Ant?“[↩]
7. I suppose I have too-lofty expectations for documentation though. What did I want? A detailed glossary of what the different @keyword annotations are for etc.–something like that?[↩]
8. I definitely think there could have been more on testing. There’s like a page and a half on PhantomJS. Having played around with it a bit myself, I feel like it could have earned a chapter all to itself. Granted, I wouldn’t want the whole book to feel like it was more about testing than the language (Grails in Action, I looking in your direction)–and since most JS books don’t mention testing at all, I’m grateful to see it get at least the chapter that it did but… I could have used a little more.[↩]
9. Also: Zakas implies that you need to run JavaScript tests in the browser and I just don’t believe that to be so. If you’re working with the DOM or BOM objects, then yes: he’s right, those are nearly impossible to accurately mock. But if you’re otherwise following functional programming patterns, and have clearly defined arguments and returns, and you avoid side-effects… Well, you should be able to unit test stuff like that without a full-blown browser at your beck and call.[↩]

About Rob Friesel