Subj : Re: Future of JS?
To   : Shanti Rao
From : Brendan Eich
Date : Thu Oct 14 2004 10:59 pm

Shanti Rao wrote:

> Brendan,
> 
> Can you tell us your long-term vision for the JavaScript language? What 
> sort of problems is it intended to solve?


JS was always intended to be easy to use -- although the C heritage 
implied by the Java- prefix, imposed by Netscape management edict when I 
created "Mocha", dictates braces and semicolons, which are not all that 
easy to use for novices (but, I added automatic semicolon insertion 
right away, to the consternation of purists ;-).

JS has always been about writing, or copying and hacking up, little 
snippets of code within "documents" (broadly construed), where these 
scripts deal with objects, strings, numbers, booleans (with loose 
conversion rules), and a few special "bottom" values.

The onclick event handler model, based directly on HyperCard, and the 
instance-tree of the DOM reflected from the nesting of HTML tags, are 
closely tied to JS's object model and type system.

So much in JS, although not the punctuator and bracketing syntax, and 
not many names and naming conventions that imitate Java, is geared 
toward economy of expression -- those "little snippets".

The trouble is Parkinson's Law.  Little snippets grow into big ones. 
The language can't be as loose or type-simplistic as awk or TCL, say -- 
it has to support some amount of programming in the large, or at least 
in the medium scale, without requiring you to write a page of 
boilerplate just to do the simplest thing.

Of particular importance are namespaces and versioning, so that 
different scripts or modules (scripts loaded into document containers) 
can present abstraction barriers bearing explicit type information and 
qualified names, which form contracts that can be maintained across 
multiple concurrent implementations, and of course across serial 
re-implementation.

It's clear to me not only from web apps and DHTML libraries, but 
especially from Mozilla's XUL apps, that classes and full-strength 
"classical O-O" are less important than modularity (namespaces, 
versioning, stronger -- but not necessarily only static -- typing, and 
information hiding).  For instance-wise modularity, JS could evolve 
classes, but one could imagine extending the current prototype system to 
support information hiding, namespaces, versions, and even multiple 
prototypes.

Operator overloading, method overloading, and generics of some sort may 
be important for ease of use and clarity of expression in some domains. 
  These too do not strictly imply classical O-O.

Optimizability may matter more than it does now.  It should be possible 
to write JS2 that can run as fast as truly equivalent native code, or 
within epsilon.  Such optimizability should come from careful language 
design with an eye on existing virtual execution sytems such as Java and 
Mono, if possible.  There should not be a need to invent a new runtime 
just for JS, although such runtimes exist now and may continue to find 
markets in the future, for various reasons.

Experience tells me that for too many of JS's problem spaces, IEEE-754 
double precision is often the wrong number type.  A rational or decimal 
numeric type extension, with sensible conversion and operator dispatch 
rules, would be a huge help for many users.

Another extension that would help many practical coders: continuations, 
a la stackless Python's generators.  Too much JS code must be written in 
a series of callbacks orchestrated via explicit state machines, with the 
callback functions having to store and recover state manually.  Such 
control-block continuation-style programming is ugly, error-prone, and 
hard to debug.  Why not let a special form of functions return a value 
without unwinding, and be resumable to return more values, indefinitely?

Yet another missing feature, implemented partially in SpiderMonkey via 
__noSuchMethod__: the ability of an object to handle get, set, or call 
on an arbitrary undefined name.

Block scope, or perhaps some more clever way of unifying closures and 
compound statements, would help certain classes of users.  The default 
creation of a global variable when assigning to a name not bound in the 
scope chain is one of the botches I knew I'd regret, but (for want of 
similarity to Java) I could not convince myself in 1995 to require the 
alternative (a TCL-like global statement to import outer names into 
functions).  So some new mode for variables seems appropriate, with the 
right compatibility defaults.

 From much of the above, it should be clear that I don't believe JS2 
must compete with C# (or with Java, with which C# clearly competes). 
Why have yet another such language?  JS's strengths are dynamism (both 
via eval and using run-time types, which enable many functions to be 
generic), Scheme-like closures, rapid prototyping from small to medium 
scale, property get and set handlers, prototype-based delegation, and 
some (sometimes unfortunately misleading) familiarity for Java and C 
hackers, whether expert or novice.

/be

.