Sunday, May 14th, 2006

Brendan Eich: JavaScript 2 and the Future of the Web

Category: JavaScript, Presentation, Programming, The Ajax Experience

We were lucky enough to have Brendan Eich, creator of JavaScript, give a keynote at The Ajax Experience.

We have placed the presentation online so everyone can read up on some of the thoughts and discussion on JavaScript 2 and more.

Here we got to hear from the mouth of someone deep into the ECMA process about what we are going to see in JavaScript 2 and importantly why:

Motivation for JS2

  • Fix problems in JS1 that bug people daily
  • A type system to enforce invariants
    • instead of writing/debugging lots of value-checking code
    • optional annotations, an extension to JS1
  • Programming in the large
    • Package system
    • Visibility qualifiers (namespaces, private internal public)
    • Optional static type checking
  • Support bootstrapping and metaprogramming
    • Self-host most of the standard objects
    • Self-host compiler front end and type checker
    • Reduce need for future ECMA Editions

As Brendan flicked through these slides, I couldn’t help but realise how important the decisions are. These changes are probably going to profoundly effect all of our lives in the near future.

Coverage on the talk on InfoWorld

Brendan Eich Keynote from The Ajax Experience

Posted by Dion Almaer at 1:09 am

4.3 rating from 33 votes


Comments feed TrackBack URI

Hi guys,
The images are broken in the slides.

Comment by Justin Palmer — May 14, 2006

Javascript 2 Presentation at The Ajax Experience

Ajaxian posted Brendan’s presentation at The Ahax Experience, called “JavaScript 2 and the Future of the Web”. Covers all the goodies JS2 will give us. One thing I noticed is the following point about class: – By default a class…

Trackback by doron's blaahg — May 14, 2006

What the…? No thread handling?

Come on…am I the only one wishing this feature?

Comment by Hakan Bilgin — May 14, 2006

fyi, if you want to actually play with an implimentation of the draft spec today, you can download the Flash Player 9 beta from:

It impliments the current draft spec, and will fully impliment the ECMA spec once it is finalized.

You can see the draft API docs for this at:

(note, Flash and Flex specific APIs are mixed in with those docs).

mike chambers

Comment by Mike Chambers — May 14, 2006

Is there audio available of this anywhere?

Comment by Jon — May 14, 2006

I am thinking that, the time interval 2006-2010 (4 years) would be somewhat too long.

Are there useful tools to speed migration?
* A JS2 to JS offline translator, for example
* Write your web app using JS2 exclusively
* Run the translator over all of your JS2 code
* Serve the translated files to old browsers

The project Java2Script, which I am working on, is providing a Java to JavaScript convertor. To develop web applications, it recommends the way of writing JavaScript in Java Syntax (Actually writing Java totally by IDE and then converting Java to JavaScript).
But some comments sound

“Don’t turn it into Java!”

These comments do bewilder me and make me think further.
From the above Brendan’s presentation, we can see a lot of syntax improvements, which are popular in Java, C++, Python or Ruby. Maybe we could call them syntax sugars. Sugars won’t be enough. Robust IDEs are needed to help writing or managing those scripts.
So I am thinking: Will JavaScript 2 be on a way of being another language if it is not adopted widely and quickly by Browsers and IDEs while JavaScript 1 keeps being popular? If such things happen, a maybe JS2 to JS converter will always be used. Then JavaScript 2 will be similar to other languages like Java, Python, as those languages also can be converted into JavaScript by convertors. Then a question: why wait 2~4 years or longer for JavaScript 2 syntax sugars? Why not having the syntax sugars of Python, Ruby, Java or C++ right now by convertors?

PS: It seems that I am deeply affected by Java2Script to make such comments on JavaScript 2.

Comment by josson smith — May 14, 2006

【JavaScript】JavaScript 2 and the Future of the Web

JavaScript 2 and the Future of the Web(The Ajax Experience 2006) #from

Trackback by JavaScript++かも日記 — May 14, 2006

um… What’s the advantages of bootstrapping JS2 and making it self-hosting?

Comment by Valkyrie — May 14, 2006

Oh the irony: the presentation doesn’t work properly in Firefox on Linux (1.5/fc5).

I’ll look at it at home on the Mac though, quite curious.

Comment by frosty — May 15, 2006

My prediction of four years till JS1 doesn’t matter was based on how long ECMA-262 Edition 3 took to displace older versions of JS from Netscape 2, 3, and 4, and IE 4.x.

IDEs are already appearing for JavaScript and Ajax, e.g., IBM’s Eclipse-based stuff.

Translators help authors use the new language only, even though not all browsers immediately support it. But as I said at the talk, at least Firefox and (I am betting) Opera will support the new edition quickly. Translating JS2 to JS1 will result in larger downloaded code size, reduced performance, greater difficulty debugging, and just greater bother than shipping JS2 source straight to browsers. So as Firefox and other browsers support the new language, any developer using such a compiler will want to bypass it when serving content to Firefox, et al.

This will likely put pressure on all browsers to support the new version.

There’s not much to be done about old browsers in the field, but we have many examples (XUL apps, Firefox extensions, web apps that target Firefox only, say in a kiosk or an intranet, and of course the Firefox front end itself) that we know will benefit from JS2.

Josson: Java and JavaScript are quite different languages. Why would you want to write one in the other’s syntax?


Comment by Brendan Eich — May 15, 2006

I think threading belongs at the API level. And convenient closures make synchronized blocks a lot less interesting anyway.

Comment by Tom — May 15, 2006

Brendan, the way for JavaScript 2 in browser sounds feasible. Actually I am not qualified to say things is feasible or not. I just hope IE will keep its pace with other browsers or otherwise drop its market share.

Writing JavaScript in Java’s Syntax is for the abilities of refactoring large scale of scripts easily and reusing some APIs from Java, for example Eclipse SWT API for new HTML widgets.
About refactoring JavaScript, I had a pain experience of managing a 200k+ *.js (Sure, nowadays, we abuse large JavaScript). I want to refactor those JavaScript into new structures, or rename function names, or change the inheritances, or other things. That time, I had to do the job by searching and replacing without robust JavaScript plugin. But meanwhile such refactoring was just a piece of cake for Java in Eclipse. These days, IDEs for JavaScript, such as JSEclipse or others, come up, but not as robust as Java tools in my opinions.
There are lots of mature APIs and implementing codes in Java which can be reused. This is another reason of writing JavaScript in Java‘s syntax. In my opinions, JavaScript is designed for script without lots of library APIs. But as things developing, more and more functions are on the way of being implemented by JavaScript. So API comes to the way. APIs need times to be verified and be implemented. Then, why not just reusing Java or Python or other language’s mature APIs and implementations? I think, the next JavaScript concepts, like “package”, “namespace” and others, do help we developing new APIs and libraries.

/js (@_@)

Comment by josson smith — May 16, 2006


Trackback by hacked.brain — May 23, 2006

As I viewed Brendan Eich’s presentation I couldn’t help but feel that though the reasons for change to the JavaScript language are valid, the proposed approaches will have a profoundly negative effect if implemented.
Two of JavaScript’s strongest assets are its ease of use and extensibility. Many of the outlined proposals will complicate the language and obscure these inherent strengths.
JavaScript became popular because of its ease of use and has remained popular because of its flexibility. These factors should be at the forefront when considering changes to the language.
A Key Problem:
In its current state, JavaScript is used in a very disorganized fashion. The language would benefit greatly from an enhancement that facilitates easy organization of implemented functionality.
A Solution:
My solution to this problem is Ajile, a JavaScript extension that provides JavaScript with namespace management. Namespaces have proven to be an excellent approach to organizing functionality in many languages. It’s my opinion that JavaScript too can benefit from this approach.

If JavaScript was going to be changed, I’d propose the addition of inherent namespace management.

Comment by Michael Lee — May 31, 2006

self incorporation

self incorporation

Trackback by self incorporation — December 6, 2006


Comment by asdf — April 15, 2007

Leave a comment

You must be logged in to post a comment.