Err, that's totally ok. That's useful for keeping a reference to the object scope in a closure. You can't really write advanced javascript without it.

AFAIK in all the c-style languages `this` is the usual self reference. Python & Ruby are self. VB.Net is Me.

But javascript screwed `this` up and this is especially apparent when you use events where `this` ends up being the caller instead of the callee. Having a self reference in the closure allows you to fix the problem.

I think people ended up using self for a reason, it's strange enough in a C-style language that you're not expecting it to be anything, but familiar enough to be obvious. The other common ones over the years have been `_this` & `that`.

There are patterns in javascript and patterns. We need Crockford to write, "Javascript Patterns: The Good Ones".

BTW: your case on "this" is not JS, it's the the DOM interface (not part of the language). From the point of view of the DOM it's probably right: The element applies itself to a callback function (the event-handler), which is triggered by the DOM interaction. The right question is: Who is the callee?

The JS built-in solution to this problem is "Object.handleEvent". (Since anything is an object, this is a general approach.) Anyway, there is no need to overwrite one of the few predefined variables to store a reference to anything, may it be to "this" or any other.

Hmm. JS was before Ruby and Python, so it couldn't have screwed up something to be found there. (BTW: HyperTalk was also "me".)

The very nature of "this" in JS is because of late binding, probably the most important feature of JS. Since references are evaluated late, the need arises to store the reference in a variable for use in a later call. Since these are first-class objects, no problem. The standard name for this used to be "that".

My point was on the total ignorance regarding the language. Why would you want to call the variable "self", overriding built-in semantics? Why not use "window" or "document" for a change? Obviously you would not want to do this, even, if their values could be restored by the use of another closure.

The praxis of naming this "self" is just an import from other languages, proving that the author in question didn't care for the semantics of the language she/he uses. Would you do the same by a compiler directive in C, overwriting built-in semantics? Could this become a pattern? Probably not. Would you redefine "/dev" in a Unix shell for other than a hoax? Probably not.

(BTW: I do not see a need to down vote a comment that points out a feature in language semantics. With server-side scripts and web-workers the global object isn't always the browser window. There is more and more need for this reference, while it becomes obfuscated by a pattern rather questionable. And I'm rather shocked to see this pattern having become quite popular. There isn't even a handful of global system variables in JS, "Math", "Date", "this", and "self" are the only ones common to all platforms. How hard is it to respect these? There are even use cases for overwriting these, e.g. test, but then you've just rendered them useless, if you chose to overwrite them in your code.)

Edit: And in case you wouldn't see a point a made here, think of code maintainability. Let's suppose you're reading some random lines of code. "Math.sqrt", you would assume to know what this is. Provided, you're in a browser, the same would apply to "self.location". But, hey, you can't be sure nowadays.