Richard Cornford

Decent short explanation. If anyone would like an exhaustive explanation, I'd recommend comp.lang.javascript's FAQ[1]. It's overkill to if you just want a working definition, but is instrumental in understanding the underlying concepts that power closures. 1. http://jibbering.com/faq/notes/closures/

Focused on javascript, but this is a great introduction to closures: http://jibbering.com/faq/notes/closures/

agreed. Also check out 'Pro Javacsript Techniques' by John Resig. Read this article on closures which is the best description I have read of such a crucial crucial aspect of the language: http://jibbering.com/faq/faq_notes/closures.html Also read Crockford: http://javascript.crockford.com/

> You'll find yourself needing a method to add or remove classes eficiently. So you'll rewrite .addClass() and .removeClass() You don't need to rewrite it, cf. this shim [1] for example. > Then you'll need a clean way to make Ajax and callbacks. You'll rewrite .ajax() and .when() They are plenty of good Ajax implementations, for example this one [2]. If you need promises, there are good libraries too [3]. > Then you'll need to fade something in all browser. So you'll rewrite .animate() Applying a fading effect on an element shouldn't be a mandatory feature. You can just use CSS3. [1] https://developer.mozilla.org/en-US/docs/DOM/element.classList [2] http://jibbering.com/2002/4/httprequest.html [3] https://github.com/kriskowal/q

Exactly. Eventually everyone turned to feature testing and it became common sense in clj. comp.lang.javascript's FAQ on browser-sniffing: http://jibbering.com/faq/notes/detect-browser/

Not to pile on the poor guy, but he does explicitly say he "creates designs" at the top header. I'm surprised that an 'in-depth' article completely ignores closures and the peculiarities of their execution stack. [edit]: FWIW, here's a more detailed explanation about all this that seems very straightforward and complete (from 2004). http://jibbering.com/faq/notes/closures/#clIRExSc

This explanation is the most thorough I've found. It also happens to be the first Google result for "javascript closures". http://jibbering.com/faq/notes/closures/

With Firefox (Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.3) Gecko/20100402 Namoroka/3.6.3), I also got this warning. Detecting the browser instead of the features is often bad practice: http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

Please do not detect the browser! Detect the feature! Feature detection is preferred by many to browser sniffing to support future browsers: http://www.jibbering.com/faq/faq_notes/not_browser_detect.html http://peter.michaux.ca/articles/feature-detection-state-of-the-art-br… https://developer.mozilla.org/En/Browser_Feature_Detection

Indeed. Also, a slightly more succinct fix for IE6/7 would be: function foo(element, a, b) { element.onclick = function() { /* uses a and b */ }; element = null; // avoid memory leak } The closure contains a reference to foo's activation object, not to its properties. As a consequence, you can clear out the element reference after the event handler has been defined and this will break the circular reference. The above technique is also useful when creating anonymous functions for other purposes when element references happen to be lying around. Depending on how long these anonymous functions are kept alive and what you do with the elements in the meantime, this would normally lead to a memory leak (due to the dangling reference to the DOM element, rather than a circular reference as described in the article). See http://jibbering.com/faq/notes/closures/ for a seriously nerdy deep-dive into closures in JavaScript.