Glad you liked it!

Thx

Great to hear!

Glad that you liked it!

Great! And don’t worry about onload: one smal step at a time.

Thanks for all the tips and and your full explanation about closures. I really get it now! I’ll definitely check out the script fixes. Closures certaiinly look the way to go, especially as you explained above they’re very handy for OOP and encapsulation.

On an aside about onload, good job you pointed that out. I must admit I tend just to pile everything into init and have one onload, not the best way if you have a team working on a project I suppose, but never have any problem with it. I suppose one day I’ll have to catch up with the modern approach…

Nice! However, you are overwriting something on a global object, so it will not allow you to have multiple window.onload – just thought I’d mention that.

And sure, it’s a closure. Whatever you put in there, i.e. that doesn’t explicitly overwrite something that exists outside of it, is only valid and reachable from within that code. If you want to return something to the outside, though, you can use a return statement in that anonymous function, which will be returned globally.

Also: no closures are bad; IE is terrible.
But, to my knowledge, Microsoft released some separate script fixes as well. More info can be found in IE Memory Leaks Be-gone and IE’s Memory Leak Fix Greatly Exaggerated.

However, really, don’t worry about this. All major JavaScript libraries, such as jQuery and others, completely rely on closures as well. So, closures is a de-facto approach to efficient JavaScript programming.

Many thanks for the quick reply!

I’ve been playing around with self-invoking functions since your article, and came up with a simple way to “encapsulate” onload, thought you might like to see it

(function()
{
window.onload=init;
})();

This is just like your “dog” function above. But would it technically be a closure though?

Looks like closures give memory leaks to IE before version 8 (good ref is http://msdn.microsoft.com/en-us/library/dd361842(VS.85).aspx ), so they would still effect a substantial number of users right now. But are all closures bad??

Glad you liked it!
About addLinks: it is rather that within each iteration of the loop, an inner function is called immediately to get a reference to the value of i at that specific time, and then assign that value to the onclick event of the link.

> Can you have a self-invoking function without a closure?
> If so, would there be any benefit to doing this?

Well, a self-invoking rather creates a closure immediately. Then it is up to you if you want to take advantage of what’s offered with that or not.

> If you use closures, what about memory leeks?
I believe older versions of Internet Explorer had some memory issues with this, but that they should be sorted out by long. Or at least so I hope!

Many thanks for such a succinct article! I’m rather new to all this and it took a bit of time to get my head around self-invoking functions.

If anyone is still struggling, correct me if I’m wrong but for your ‘infamous loop’ problem, if for the sake of argument you call the addLinks function declaration (all the loop and stuff) ’splurge’, then am I right in thinking that the function call is done immediately by the declaration ’splurge’(i); ?

I’m curious about several other points as well:
Can you have a self-invoking function without a closure?
If so, would there be any benefit to doing this?
If you use closures, what about memory leeks?

No problem, glad you understood what I meant!