That was a *fantastic* article - thanks for that. Mind you, he never actually says that you shouldn't use closures, and [instead says](http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html):

> Until these issues are addressed classical objects might be a better choice if you are looking for a predictable performance. Though each individual case requires careful investigation (e.g. is it singleton or multiple objects are going to be produced? is it on hot path? etc). And of course don’t optimize before you need to optimize :-)

The blog post suggests that moving away from closures will be faster (only if multiple demos get instantiated). But I highly doubt that these helper methods make any significant difference in performance anyway.

I'll accept the consistency argument though.

As for the antipattern claim –

There's just so many opinions about what good javascript looks like these days - I mean, compare [Crockford style javascript](http://javascript.crockford.com/code.html) and [Google javascript](https://code.google.com/p/closure-library/source/browse/closure/goog/net/browserchannel.js). They may as well be different languages. In the NodeJS community everyone writes their code a little differently, and has different opinions about what good code should look like.

Thats a long way of saying that you shouldn't use the word 'antipattern' so glibly. You aren't doing me any favours by 'fixing' my code to conform to your view of what good code looks like – I've probably been writing javascript longer than you.

I'm happy for the increase in consistency, but without that argument (or evidence of a performance increase), I would see no reason to accept your changes.