Closure drive

I don’t much like Google’s new Closure library and compiler. Here’s why…

I have a vivid memory of watching the David Lynch movie Eraserhead where towards the end I finally turned to the person next to me and we both slowly voiced the phrase “what was that?”

I had déjà vu recently when I waded through the announcement on Google’s Closure compiler and library for JavaScript. Had I just walked into a David Lynch movie set on planet Google? Had somebody just pulled a Gordian knot tight around me? If so, with what razor could I cut it apart?

Some smart people have chimed in on the side of Google and spoken poorly of a number of common coding techniques for JavaScript programmers with Crockford’s module pattern being one example. Their complaint? That modern techniques employed by JavaScript coders were inefficient…

Dmitry then had a look at some of the Closure source code and pointed out that compilers aside, some of the coding techniques used in Closure are inefficient for JavaScript.. and that some others are just plain silly. Borrowing a phrase from Dmitry… I don’t know what they call that in Java, but I call it irony.

For the record, and to clear up any potential ambiguity caused by my often circuitous writing style. I agree with Dmitry. Other libraries such as jquery may have their issues but the design of the part that people interact with (you know, the API) is overall something other libraries would, for the most part, do good to emulate.

I had a look through the source for closure myself and whilst there’s some useful stuff in there it feels a bit like a bag of nails and is about as inspiring as one. Slider examples that use 44 different individual scripts (I’m sure the compiler fixes that right?), a unit testing framework apparently from 2009 shoehorned into code apparently written in 2004 (better late than never) and a bunch of things that really don’t seem like they belong in a decent general purpose library such as pretend constants like the one for the default size of a popup window and finally some stuff that really shouldn’t be in any JavaScript code anywhere, such as != 0. Now, there may be good reasons for these and I’m not questioning the coding ability of the people who wrote it. Instead, I’m questioning the extent to which they might still (if they ever did) consider themselves JavaScript natives. Most people coding in JavaScript stopped writing code the way suggested by the proponents of the closure compiler years ago because we were sick of fighting the language. Dmitry is one of those people and library authors should pay attention.

What bothered me about Closure more than anything though was the (apparent) accompanying mentality that they know the right way to do things and that other JavaScript programmers are living in the dark ages banging rocks together. Still, I shouldn’t be that offended that somebody has a different idea about how to write good code… and yet, there I was…

What was it that bothered me so much?

The real thing that pissed me off is a suggestion that I should write worse code to optimise for their compiler. Last I checked it was 2009 and I gladly wrote my last malloc more than ten years ago. If the interpreter or compiler wants to run better then somebody ought to fix the compiler. I’ve had enough IE6 for the last eight years to know that having to tailor my development approach to a computer, instead of to a human is nothing but pain from start to finish and that worse… spending all my time looking inwards to the computer instead of outwards invariably results in a crap user experience for the people that really matter - my users - whether that’s coders I work with or who inherit my code or users of the UI that I’m writing.

Some of us who work in JavaScript every day are trying to improve JavaScript and the coding environment to make it better. We all want to make JavaScript suck less… these other guys (yes, I’m deliberately phrasing this divisively), they’re trying to make the language suck more by making JavaScript developers kowtow to their compiler. Or worse, by making people write Java that compiles to JavaScript… but that’s a story for another day.

Pseudo-classical inheritance simply doesn’t make sense in JavaScript. JavaScript works better with object cloning, mixins, shallow (think wading pool) hierarchies, literal notation, and closures. Trying to do elaborate inheritance in JavaScript generally ends up in dog shit. I know because I’ve stepped in it.

It would be nice to get some more of Self into JavaScript… in other words, it would be nice to have a better prototypal system with dynamic inheritance and traits. I would need to see the associated complexity tax tested first though as I’m not sure if the language can float those but perhaps… and perhaps multi-methods, perhaps macros… I’m not sure, I’ll leave that to the language designers.

Anyway, it would not be better to get more of C++ into JavaScript. People absolutely need to remember that. The world has moved on.

Yes, personal preference but… Friends of Closure, please stop telling people they’re doing things wrong because based on your development style and using your compiler your way works better for you.

Finally… just to really nitpick, the name really blows. Both because the library doesn’t feel especially functional and because it sounds too much like the completely awesome Clojure language…

CoffeeScript in Action

CoffeeScript in Action book cover

I'm the author. Get it from Manning.