Closure: The world's most misunderstood JavaScript library

August 9, 2010

Last year, Google released the Closure suite of tools for JavaScript development. It seemed too good to be true. A robust client-side JavaScript toolkit and UI framework was just what I missed in my stack.

I quickly downloaded the distribution and, like the rest of the world, was immediately disappointed: The source looked like Java, with long name spaces and getters/setters everywhere. The compiler looked interesting but difficult to setup and integrate in the build process. The templating engine looked ugly and required a compile step. I switched back to jQuery faster than you can say 'crap'.

The problem is I wasn't fond of jQuery either. It 's great for improving the interactivity of a page or adding special effects but leaves a lot to be desired when you are building a business-oriented Web application. As I am working on a series of Web applications for deployment through Google Apps Marketplace I decided to give Closure a second chance.

I followed a couple of online tutorials, browsed through the online API reference and the thoroughly commented source code and experimented with some demo apps. Eventually, the concepts of Closure started to sink in. But still, I had like hundreds of questions.

That's when I decided to buy the Closure, the definitive guide book, available as a Rough Cut from O'Reilly. What a great book! The author painstakingly discuses the design rationale behind the Closure tools and exposes the benefits of the suite. The Closure library is genetically engineered to work with the Closure compiler and the Google developers behind it are really obsessed with performance, memory consuption, compatibility and code safety/debugability. The whole system is optimized for bigger development teams, not quick Web page hacks.

Among other things, I learned that:

  • the powerful type system eliminates a large class of bugs
  • the compiler eliminates the long name spaces (and the corresponding run-time look ups)
  • getters/setters actually lead to better compression
  • you can split the client side code in multiple, independently loaded modules
  • the pseudoclassical pattern used for OOP is actually better than the functional pattern (when combined with the Closure compiler)
  • you can easily extend the Compiler with extra features...

...and so much more. I don't want to spoil your fun, just grab this great book. It's the only way to really get into Closure. Heck, I would recommend this book even if you are not interested in Closure, it will make you a better JavaScript programmer.

Don't get me wrong, no tool is really perfect. Closure still has some issues: no CommonJS compatibility (but then again, CommonJS seems kind of dead these days), limited support from Google (they seem to be pushing GWT instead) and a shallow community around the project. Still, Closure suits my needs better than other solutions.

The verdict? Buy Bolin's excellent book and give Closure a try!