zumbrunn.com

Future of Javascript Roadmap

Brendan on JavaScript 1, 2, and in between.

"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."

  • JS is not going away, so it ought to evolve.
  • JS does not need to become Java, or C#, or any other language.
  • JS does need some of its sharp corners rounded safely.
  • JS should make it trivial 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.
One sharp corner that I would like rounded safely would be to make that methods can be added to the Object and Array prototype without breaking for/in loops. The beauty of Javascript is that additional methods like String.trim() and String.md5() can easily be added to the existing prototype via your own script library. One way to make the same possible for the Array and Object prototypes would be allowing the enumeration to be suppressable on a per property bases...

dontenum Array.prototype.contains

...as recommended by Douglas Crockford.

Regarding reserved identifiers, it certainly seems inconsistent to allow...

var foo = {'var':bar};
return foo['var'];
...while...

var foo = {var:bar};

return foo['var'];

var foo.var = bar;

return foo.var;

...are not allowed.

14.06.2005, 07:56