Re: "elegant": I think you are crazy. (I program in Javascript all the time professionally and wrote a compiler to it for my dissertation.) It has numerous design blunders at its core, like requiring everything to be accessible through string-based names and hashes at runtime, except when very sophisticated compilers can tell that very simple code does not require this; its notion that erroneous expressions should continue execution by propagating "undefined" instead of telling the programmer; treating everything as an object in a misguided attempt to achieve uniformity but then requiring a whole host of exceptions and special cases because of course, functions are actually different from integers after all. Of course I disagree on its matters of taste regarding types, and balk at ideas like in v5 of adding "yield" (a complicated beast instead of something actually simple and well-understood like continuations), or whatever. But I don't need to defer to taste to make my point.

Just open up the (massive) ECMAscript definition. You'll witness that the language definition is literally the codification of the C program (see e.g. the 54-step description of the Array.prototype.splice function, filled with GOTOs and k++s on ECMA-262 p.95) that some Netscape engineers (possibly good hackers, but who certainly did not understand programming language design nor that their code was going to become forever entrenched in the tower of garbage we're now building the information age on) crapped out on a coffee binge to fix some demo script written by some other language-naive hacker which script they both basically agree should work because it seems natural or some such. Without any regard to language-wide implications. I've been on projects before that built languages that way so the symptoms are easy to recognize. Examples are everywhere: Automatic semicolon insertion? That as a result some productions in the grammar (e.g. x++) have special cases banning newlines between tokens? The inscrutable contextually-dependent semi-sameness of 0, null, false, undefined, 0.0, "", {}? That there are multiple internal intermediate values that are required for explaining the semantics of the language, but that cannot be expressed in the language? That its grammar is such that almost every phrase is defined with both regular and "NoIn" versions (e.g. BitwiseANDExpressionNoIn), the latter being identical but not containing the "in" keyword, so that they can explain the behavior of the parser they inherited (I can only imagine what it looks like)? That there is no actual character type, so strings are only usable as arrays of length 1 strings (themselves arrays of length 1 strings, i.e., infinite objects)? Not to mention all the crazy stuff you can do by modifying built-in prototypes (I called a function and now every array has a 4th element of your choosing?) or properties of the global object like undefined and null (Why aren't they just literals like true and false?).

And what about this gem (ECMA-262, p.121): Not even an explanation? Is this some kind of fucking joke??

At least p.139 cites its sources:

Re: "Lexical scope": my ass. I don't think there is a single thing in the language that is lexically scoped. There aren't even variables. My eyes glaze over when I try to understand the details, but roughly speaking, every "variable" is a property of some object, usually the activation of the function body you're currently evaluating. Like what do you think this code does?

function installHandlers() {
   for (var i = 0; i < 20; i++) {
     var elt = document.createElement('div');
     document.body.appendChild(elt);
     elt.innerHTML = i;
     elt.onclick = function() {
       alert('Clicked #' + elt.innerHTML);
     };
   }
}


You get 20 boxes with numbers, but if you click, the message always says #19. Why? The mention of elt in the function looks up the property called elt in the activation object for the call to installHandlers. There's just one: Even though I'm saying "var elt = ..." what that really means is find the property elt in the closest function scope and modify it to this new value. The var keyword has nothing to do with variable declaration, in other words. There are plenty of ways to write this code where you get the behavior seemingly intended by the above code (most involving introducing extra function definitions and calls so that you get new objects for them) and seasoned JavaScript programmers get along fine with it, but this isn't lexical scoping (it isn't even dynamic scoping!).