Maintainable JavaScript By Nicholas C. Zakas
Over the weekend, I finished reading the early release edition of Maintainable JavaScript, Writing Readable Code by Nicholas Zakas. To be honest, I had no idea what this book was about before I purchased it; it was by Nicholas Zakas, and that's all I really needed to know before I made my decision. That said, this was book was not exactly what I thought (or perhaps hoped) it would be; since Zakas has often written about application architecture, I had hoped this book would be an in-depth exploration of how application architecture can lead to more "maintainable JavaScript". It turns out, however, that this book was much more focused on consistent formatting, high-level understanding of the language, general "best practices", and a huge amount of automated testing and deployment. In the end, while not what I expected, it has a great amount of valuable information.
| |
|
|
||
| |
 |
|
||
| |
|
|
The book starts out with an awesome quote by Donald Knuth:
Programs are meant to be read by humans and only incidentally for computers to execute. (Page 14 of 360)
I absolutely love this perspective! Too often, we as developers worry about micro-optimizations where readability is placed second to the shaving-off of milliseconds of execution time. But, as Zakas points out, 80% of the lifetime of software goes towards its maintenance. Making sure that we have clear, consistent, readable, decoupled code is an investment that is critical to the long-term success of a project. As such, it is no wonder that the first third of the book goes into defining and discussing all aspects of code formatting. This includes everything from commenting, to white-space, to loops, to property look-ups, to comparison operators, and to when its considered appropriate to use NULL values.
The second 3rd of the book is about Programming "best practices." This is the part of the book that I was initially hoping to find. And, as much as this section did have some really great insights, it was definitely more focused on high-level and language-specific best practices than it was on actual application architecture. For example, Zakas talks about how Event objects should not be passed around in order to avoid ambiguous APIs; but, he doesn't go into much detail about how a user interface (UI) widget (which handles events) should communicate with the application in which it is being used.
As I reflect on this section, I am realizing that there is actually a lot of gold here. Zakas makes me think about things that I hadn't really considered before. I guess I just wanted a little more hand-holding with tying all of the concepts together in a single application. I suppose that's where I am currently feeling the most pain in my understanding of programming.
The last 3rd of the book, which felt like the bulk of the book, dealt with Automation: testing, building, compressing, compiling, and deploying. A lot of this talks about Ant and about all of the automation tasks can be done inside of Ant. Zakas also demonstrates a custom Ant library that he built - Buildr - which simplifies many of the Ant tasks that we'd want to run when automating a project's lifecycle.
I've never used Ant (or any kind of automation) before; so, this section felt a bit foreign to me. That said, since I've never used Ant, this is probably the most valuable section of the book for me personally. As I was reading, I was definitely having a strong emotional reaction to the fact that this felt so "meta" to any of my current programming problems; but, in hindsight, this kind of automation is a huge gap in my software development workflow and is something that I should really start to take more seriously.
Right now, I feel like I have a fairly good understanding of the languages that I use; but, I definitely feel shaky when it comes to building complex, modular, decoupled applications. As such, I was hoping this book went into more depth in terms of actual architecture. When it didn't, I think I started to get distracted by my own emotional reaction and insecurities. This prevented me from seeing and appreciating all of the great information that Zakas discusses. In hindsight, I can see there was a lot of value that I failed to absorb properly. Understanding the goal of the book, I need to go back and read it again so I that I can really internalize all of the knowledge Zakas was laying down.
Reader Comments
Ben, thanks for the review, I look forward to reading this book.
@Derek,
Excellent - hope you like it!
Thanks! I really think the last 3rd is where the gold would be for me. I spend a lot of time thinking about testing, building, compressing, and deploying javascript. It would be great to get another perspective. Thanks!
Might give this book a crack, love the quote and it's so true!
@UnseenRevolution,
Definitely; and for me, it's a reminder that I *have* to start looking into this stuff.
@Joey,
Another quote I really liked at the beginning of Part II was:
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way way is to make it so complicated that there are no obvious deficiencies." - C.A.R. Hoare, The 1980 ACM Turning Award Lecture (Page 96 of 360)
Hi Ben,
Thank you for this review. Maintainable JS is on my reading shelf, so I was very interested by your post.
Have you read JavaScript Web Applications by Alex MacCaw? I am almost finished with it and I think you might enjoy the read as it covers building complex javascript web application in depth.
Link: http://shop.oreilly.com/product/0636920018421.do
Cheers
@JP,
Thanks for the recommendation. I actually read JavaScript Web Applications a little while back and absolutely loved it.
www.bennadel.com/blog/2201-JavaScript-Web-Applications-By-Alex-MacCaw.htm
It was the first time I had really read anything in-depth about Backbone.js or Spine.js. Now that you mention it, I should probably go back and re-read it. There so much freaking information out there and there's only so much my brain can absorb at a time. Unfortunately, this requires a sort of iterative approach on learning :)
Speaking of iterative reading, I'm thinking of looking at Head First Object Oriented Analysis & Design... which I don't think I've read (I might be confusing it with Head First Design Patterns or Head First Java).
Brain hurt :D