I've written about the early history on my blog: http://Weblogs.mozillazine.org/roadmap/archives/2008/04/popularity.html.
The impetus was the belief on the part of at least Marc Andreessen and myself, along with Bill Joy of Sun, that HTML needed a "scripting language", a programming language that was easy to use by amateurs and novices, where the code could be written directly in source form as part of the Web page markup. We aimed to provide a "glue language" for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the "component language" used by higher-priced programmers, where the glue programmers -- the Web page designers -- would assemble components and automate their interactions using JS.
In this sense, JS was analogous to Visual Basic, and Java to C++, in Microsoft's programming language family used on Windows and in its applications. This division of labor across the programming pyramid fosters greater innovation than alternatives that require all programmers to use the "real" programming language (Java or C++) instead of the "little" scripting language.
So was there a particular problem you were trying to solve?
The lack of programmability of Web pages made them static, text-heavy, with at best images in tables or floating on the right or left. With a scripting language like JS that could touch elements of the page, change their properties, and respond to events, we envisioned a much livelier Web consisting of pages that acted more like applications.
Indeed, some early adopters, even in late 1995 (Netscape 2's beta period), built advanced Web apps using JS and frames in framesets, prefiguring the "Ajax" or "Web 2.0" style of development. But machines were slower then, JS had a relatively impoverished initial set of browser APIs, and the means to communicate with servers generally involved reloading whole Web pages.
See my blog post, linked above.
Why was JS originally named Mocha and then LiveScript?
Mocha was Marc Andreessen's code name, but Netscape marketing saw potential trademark conflicts and did not prefer it on other grounds. They had a 'live' meme going in their naming (LiveWire, LiveScript, etc.). But the Java momentum of the time (1995-1996) swept these before it.
ECMA-262 Edition 3 is the latest ECMAScript standard. Edition 1 was based on my work at Netscape, combined with Microsoft's reverse-engineering of it (called JScript) in IE, along with a few other workalikes from Borland and a few other companies.
Were there any particularly hard/annoying problems you had to overcome in the development of the language?
Yes, mainly the incredibly short development cycle to prove the concept, after which the language design was frozen by necessity. I spent about ten days in May 1995 developing the interpreter, including the built-in objects except for the Date class (Ken Smith of Netscape helped write that by translating Java's java.util.Date class to C, unintentionally inheriting java.util.Date's Y2K bugs in the process!)
I spent the rest of 1995 embedding this engine in the Netscape browser and creating what has become known as the 'DOM' (Document Object Model), specifically the "DOM level 0": APIs from JS to control windows, documents, forms, links, images, etc., and to respond to events and run code from timers.
I was the lone JS developer at Netscape until mid-1996.
We are seeing more games, both new and ported from other implementations, as well:
And John Resig's port of the Processing visualization language takes the cake.
And what's the worst?
I couldn't possibly pick one single worst JS program. I'll simply say that in the old days, JS was mainly used for annoyances such as pop-up windows, status bar scrolling text, etc. Good thing browsers such as Firefox evolved user controls, with sane defaults, for these pests. Netscape should have had such options in the first place.
Have you ever seen the language used in a way that was not originally intended? If so, what was it? And did it or didn't it work?
The Java VM (Orto) mentioned above is one example. I did not intend JS to be a 'target' language for compilers such as Google Web Toolkit (GWT) or (before GWT) HaXe and similar such code generators, which take a different source language and produce JS as the 'object' or 'target' executable language.
The code generator approach uses JS as a 'safe' mid-level intermediate language between a high-level source language written on the server side, and the optimized C or C++ code in the browser that implements JS. This stresses different performance paths in the JS engine code, and potentially causes people to push for features in the Ecma standard that are not appropriate for most human coders.
JS code generation by compilers and runtimes that use a different source language does seem to be 'working', in the sense that JS performance is good enough and getting better, and everyone wants to maximize "reach" by targeting JS in the browser. But most JS is hand-coded, and I expect it will remain so for a long time.
Yes, we have plans to address these, both through the standards bodies including the W3C, and through content restrictions that Web developers can impose at a fine grain. See the document:
and the Mozilla bug tracking work to implement these restrictions:
I expect the 3.1 edition of the ECMA-262 standard will be done by the middle of 2009, and I hope that a harmonized 4th edition will follow within a year. It's more important to me (and I believe to almost everyone on the committee) that new editions of the specification be proven by multiple interoperating prototype implementations, than the specs be rushed to de-jure approval by a certain date. But the 3.1 effort seems achievable in the near term, and a harmonized major 4th edition should be achievable as a compatible successor in a year or two.
The improvements in the 3.1 effort focus on bug fixes, de-facto standards developed in engines such as SpiderMonkey (e.g. getters and setters) and reverse-engineered in other browsers, and affordances for defining objects and properties with greater integrity (objects that can't be extended, properties that can't be overwritten, etc.).
The improvements for the harmonized major edition following 3.1 simply build on the 3.1 additions and focus on usability (including new syntax), modularity, further integrity features, and in general, solutions to 'programming in the large' problems in the current language.