Pretty much all mature languages are defined by a specification, and compilers or interpreters attempt to follow the standard defined in that specification. But very rarely do they succeed, unless the standard is defined by the author of the language.

You can find the C++ 2003 standard, the C# 4 specification, the Java 7 specification and many more online. Many of these have ECMA or ISO standardisation numbers. These are just organisations with which you can register a standard and make it more official.

Ruby has historically done things a little differently, having an executable set of tests as a specification. So, if you want to write an interpreter and call it standard Ruby, you just had to create an interpreter that passed all of those tests. But even Ruby is likely to become a more formal specification eventually.

Javascript is no different, except possibly in the way it has evolved.

Javascript was first created by Netscape. They called it LiveScript, but it looked similar to Java and they cut a deal with Sun over the name, which benefited both the marketing of Netscape and Java. Microsoft had VBScript and (for reasons probably lost to conjecture) basically copied Javascript, but the name was owned by Sun, so they cheekily called it JScript.

But JScript, while being very similar to Javascript in syntax, made a lot of use of COM — for example, IE5 and 6 instantiate an XMLHttpRequest object using new ActiveXObject("Microsoft.XMLHTTP");.

And so, parallel, similar but also different “dialects” of Javascript were born. Over time, various groups owning browsers with less market share than IE have tried to standardise the language, and for years Microsoft resisted. Until V8.

V8 was fast. It set a whole new market standard. It made everything else look poor.

And, through various antitrust cases against Microsoft, IE was losing market share. Suddenly, it was in Microsoft’s interest to support standardisation. We’re not there yet, but it’s on the right track.

Meanwhile, V8 was open-source, which allowed people to start thinking up new uses for a fast Javascript parser, such as Node.JS.

But, to go back to your question: What is Javascript? It’s the common (and original) name for ECMAScript, a specification for a prototypical language commonly, but not exclusively, used for navigating and manipulating the domain object model in a broswer.

ECMA-262 is just the standard definition, like ECMA-334 is the standard definition for C#. ECMAScript was the only name that all the interested parties could agree on, back in ’99, when ECMA-262 was written.

Javascript is a commonly used implementation of ECMAScript. It’s a very similar situation to the Scheme family. In Scheme, you have a highly formalized specification. The current version is R6RS though R5RS is by far the more commonly implemented standard as of this post. The implementations are more scattered than ECMAScript’s due to Scheme’s age and general philosophies.

Javascript happens to be common now largely due to the explosive growth in market share of both Mozilla’s Firefox and Google’s Chrome. It gained a foothold originally with Netscape Navigator which eventually turned into the Mozilla browser and then into Firefox (and Iceweasel if you run with the Scheme crowd).

Now here’s where it gets a little dicey. Most of Javascript’s performance comes from the parser and engine running it. This is where the real differences between browsers become apparent. Spidermonkey runs Javascript differently than V8 does. Javascript still have rough spots like the lack of a fully common library, though that’s being worked on.

So if Javascript were C++, then ECMAScript would be the C++11, with UNIX and G++ being the closest to “standard” while C++ for .NET and Objective C++ lie further afield much in the way Actionscript does from ECMAScript