It is commonly stated that you can write a big JavaScript program but you can't maintain it. So a book that claims that maintainable JavaScript is possible sounds like a must read. Or is it?

The problem for any book on this topic is that there is a great deal of information around already on what makes good JavaScript style and how to use good software engineering techniques to make what you produce better. The criticism leveled at JavaScript is made in the knowledge of all of this "best practice". The argument that has to be defeated is that JavaScript is inherently unruly in ways that style cannot fix.

Part 1 of Nicholas Zakas' book is all about style, and if you have been programming in JavaScript for any length of time there is nothing new to discover here. It is well explained, however, and it would make a good source book if you were trying to set up a style guide. Topics covered include how to format your programs, using comments, naming variables, using control statements and declarations. As stated, all well written and well argued. If you don't know these ideas then this is an excellent potted guided to writing JavaScript in good style.

The second part of the book is about larger scale issues and not just the way the code sits on the page. This is potentially much more interesting. First we have a look at the ideas of loose coupling with the UI. The advice here is to keep the separation of the layers - HTML, CSS and JavaScript. Good advice, but more difficult to achieve than you might think, and at the moment I don't think there is a really good solution. Next we look at the implementation of namespaces using objects and controlling code using modules. A better way of crafting event handlers is also introduced along with separating data from code, dealing with exceptions and browser detection. All of this is welcome but there isn't anything radical in the mix. If you already know about these ideas, possibly from you experience with other languages then there isn't much for you to read here.

The problem is that JavaScript isn't a class based language and it is so weakly typed that you hardly notice that it is. Working with JavaScript is very different from working with Java or C# say. You can do things that you can't do in these strongly typed languages. There are so many things that this section of the book should deal with and doesn't. There is the issue of mixins, closures, promises, functional programming, how to use prototype, object organization and so on. What is said in Part 2 is all correct, but it hardly scratches the surface of how JavaScript can be used and how it should be used.

The final part of the book is called "Automation" and it is just the standard techniques used in other languages applied to JavaScript. For example the first thing we learn is that you should have just one object per JavaScript file - this is a Java convention and it applies to one class per file not one object. This is not particularly an idea that should apply to a dynamic language like JavaScript that doesn't have classes. The rest of the section discusses the Ant build system, code validation, minification and compression, documentation and testing. All of which you should know about, but they hardly make a remarkable contribution to creating maintainable JavaScript.

In the end this book suffers from simply repeating much of the advice and ideas that surround using strongly-typed, class-based languages. Perhaps one solution to making JavaScript programs maintainable is to turn JavaScript into Java or C#, or whatever your favorite language is, but this is to miss the point. JavaScript is very different from these classical languages and it has the potential to be more productive and more maintainable.

Does this book tell you how to create maintainable JavaScript?

No. But you still need to know the ideas it expresses and you need to take JavaScript development as seriously as it does.

Should you read this book?If you don't know about good style and good programming practices that mostly apply to other languages then yes, because you need to know this.