H ? « ‹ ← → › »

Language peer sets for JAVASCRIPT:
United States↑
United States/1995↑
Designed 1995 ↑
1990s languages ↑
Fifth generation↑
Post-Cold War↑

JAVASCRIPT(ID:2133/jav008)

alternate simple view

Country: United States
Designed 1995

Now ECMASCRIPT

Brendan Eich Netscape 1995

a scripting language developed by Netscape to enable Web authors to design interactive sites. Although it shares many of the features and structures of the full JAVA language, it was developed separately. JAVASCRIPT can interact with HTML source code, enabling Web authors to spice their sites with dynamic content. JAVASCRIPT is endorsed by a number of software companies, and it is an Open Source product that anyone can use without purchasing a license. It is supported by recent browsers from Netscape and MS; although IE supports a subset, which MS calls JSCRIPT. "Within HTML, JAVASCRIPT reigns supreme and is the default script. It has C++ and JAVA like structures and can port some of the C/C++ and JAVA code. JAVASCRIPT basically extends the HTML language, but it's scope seems confined to the browser". http://javascript.com http://javascript.internet.com

Related languages

LiveScript	→	JAVASCRIPT		Renaming
JAVASCRIPT	→	ECMASCRIPT		Evolution of

Samples:

References:

Eichs, Brendan (1998) Eichs, Brendan "Making Web Pages Come Alive" TechVision column (June 24 1998) at NS website Extract: Anecdote

Marc Andreessen (1998) Marc Andreessen "Innovators of the Net: Brendan Eich and Javascript" TechVision column (June 24 1998) at NS website

Danny Goodman, Brendan Eich (2001) Danny Goodman, Brendan Eich "JavaScript Bible, Gold Edition" John Wiley & Sons NY 2001 Extract: LiveScript becomes JavaScript Extract: JavaScript: A Language for All

Brockmeier, Joe (2002) Brockmeier, Joe "The Problem with JavaScript" NewsFactor Network Report December 17, 2002

(2002) Library of Congress Subject Headings J39
Resources

BLog on JS With DHTML and AJAX hot (or hot again; we've been here before, and I don't like either acronym), I am asked frequently these days about JavaScript, past and future. In spite of the fact that JS was misnamed (I will call it JS in the rest of this entry), standardized prematurely, then ignored and stagnated during most of its life, its primitives are strong enough that whole ecologies of toolkit and web-app code have emerged on top of it. (I don't agree with everything Doug Crockford writes at the last two links, but most of his arrows hit their targets.)

Too many of the JS/DHTML toolkits have the "you must use our APIs for everything, including how you manipulate strings" disease. Some are cool, for example TIBET, which looks a lot like Smalltalk. Some have real value, e.g. Oddpost, which Yahoo! acquired perhaps as much for its DHTML toolkit as for the mail client built on that toolkit.

Yet no JS toolkit has taken off in a big way on the web, probably more on account of the costs of learning and bundling any given API, than because of the "you must use our APIs and only our APIs" problem. So people keep inventing their own toolkits.

Inventing toolkits and extension systems on top of JS is cool. I hoped that would happen, because during Netscape 2 and 3 days I was under great pressure to minimize JS-the-language, implement JS-the-DOM, and defer to Java for "real programming" (this was a mistake, but until Netscape hired more than temporary intern or loaner help, around the time Netscape 4 work began, I was the entire "JS team" -- so delegating to Java seemed like a good idea at the time). Therefore in minimizing JS-the-language, I added explicit prototype-based delegation, allowing users to supplement built-in methods with their own in the same given single-prototype namespace.

In listening to user feedback, participating in ECMA TG1 (back during Edition 1 days, and again recently for E4X and the revived Edition 4 work), and all the while watching how the several major "JS" implementors have maintained and evolved their implementations, I've come to some conclusions about what JS does and does not need.

JS is not going away, so it ought to evolve. As with sharks (and relationships, see Annie Hall), a programming language is either moving forward, or it's dead. Now dead languages (natural and programming) have their uses; fixed denotation and grammar, and in general a lack of "versionitis", are virtues. You could argue that JS's stagnation, along with HTML's, was beneficial for the "Web 1.0" build-out of the last decade. But given all the ferment on the web today, in XUL and its stepchildren, and with user scripting, there should be a JS2, and even a JS1.6 on the way toward JS2.
JS does not need to become Java, or C#, or any other language.
JS does need some of its sharp corners rounded safely. See the table below for details.
Beyond fixing what was broken in JS1, JS should evolve to solve problems that users face today in the domains where JS lives: web page and application content (including Flash), server-side scripting (whether Rhino or .NET), VXML and similar embeddings, and games.
For example, it should be trivial in a future version of JS to produce or consume a "package" of useful script that presents a consistent interface to consumers, even as its implementation details and new interfaces evolve to better meet existing requirements, and to meet entirely new requirements. In no case should internal methods or properties be exposed by default.
It's clear to me that some users want obfuscated source code, but I am not in favor of standardizing an obfuscator. Mozilla products could support the IE obfuscator, if someone wants to fix bug 125525. A standard obfuscator is that much less obscure, besides being unlikely to be adopted by those who have already invented their own (who appear to be the only users truly motivated by a need for obfuscation at this point).
A more intuitive numeric type or type tower would help many users, although to be effective it would have to be enabled via a new compile-time option of some sort. Numeric type improvements, together with Edition 4's extensible operator and unit proposals, would address many user requests for enhancement I've heard over the years.
Too much JS, in almost every embedding I've seen, suffers from an execution model that appears single-threaded (which is good for most users) yet lacks coroutining or more specific forms of it such as generators (Boo has particularly nice forms, building on Python with a cleanup or two). So users end up writing lots of creepy callbacks, setTimeout chains, and explicit control block state machines, instead of simply writing loops and similar constructs that can deliver results one by one, suspending after each delivery until called again.
That's my "do and don't" list for any future JS, and I will say more, with more specifics, about what to add to the language. What to fix is easier to identify, provided we can fix compatibly without making a mess of old and new.

Search in: Google Google scholar World Cat Yahoo Overture DBLP Monash bib NZ IEEE ACM portal CiteSeer CSB ncstrl jstor Bookfinder