Today, I had the privilege of speaking with Brendan Eich, CTO of Mozilla Corp. and the creator of JavaScript. Brendan and his cohorts on the ECMAScript 3.1 committee recently finished working out the details for what will become the next version of JavaScript. Rather than cut up his words into a story, I'm just going to post the interview verbatim. There's no real need to break it up. Herein, he explains what the next JavaScript means to developers. Below is the interview, uncut.
Part of it is things we already have in
Firefox, like getters and setters. Accessor properties. Those had
been in demand, and other browsers implemented them. Safari and
Opera, and I think Microsoft is finally going to do it. They have an
implementation of the Fifth Edition in Jscript.
Other things we've done are things that
have become de facto standards, like extra methods on array objects.
Now, if they aren't there, like in IE, they have to download code and
implement them in JavaScript.
These are all things that were de facto
standards that are now de jure standards. There's innovation beyond
that. A lot of that is work to make it possible to improve the
integrity of the language. To prevent names from being rebound and
stolen. It's reflective meta-programming. What properties are there?
What you want to add you can add with getters and setters, and you
can set properties that can't be changed.
Work to implement these are already
under way for Mozilla, probably after the Firefox 3.5 release. We'll
be testing it out in our nightly builds and beta releases. We're at
the candidate recommendation stage, where we think the standard's
good. It's good having Microsoft experiment with their prototype.
I've seen it. We have at least two prototype editions that can be
tested.
We're not standardizing prematurely.
We're not going to stamp a rubber stamp on something that has never
been tested. We're going to test this stuff in the field.
There is hardly any new syntax. This
reflective meta-programming API, what it means is you can make
objects that look more like host objects: the magic objects you can
set in the DOM.
We've had getters and setters for 10
years now, but when Microsoft launched Live Maps, they had a bunch of
new JavaScript code that was like AJAX code. They called it Atlas at
the time. It would model the DOM assuming it was IE. If it wasn't,
they'd use these getters and setters, these precursors to make the
DOM look like IE's DOM. They only seemed to care about this for
Firefox. What this immediately caused was pressure on Safari and
Opera to go implement getters and setters.
A lot of JavaScript is forked. If the
DOM is IE, use this version of the code, otherwise use this. When
Live.com launched and started assuming getters and setters worked
there, there was an immediate need for that functionality in other
browsers. That's an example of how the Web works if everyone
cooperates.
Here, we've managed to cooperate.
Beyond the getters and setters and
array extra methods and reflective meta-programming, we have strict
mode now. Say I want
to have more error checking, or have some sanity checks done. When
you assign to a read-only property, it shouldn't just fail. With
strict mode you get an exception. The hope is a lot of people will
just turn it on. People got used to seeing 'use strict' at the top of
their Perl code. This will help us evolve the language so that
someday, many years down the road, we can make the general language
stricter.
JSON has dethroned XML for pure data
interchange. But it has had to be implemented as a JavaScript
library. You have to be careful how you use it. With this new codec
as part of the standard, they don't have to worry about downloading
the libraries. There are other improvements to the integrity of JSON,
so when you make arrays and objects from decoding this string, you
get arrays and objects, not some attack encoded inside it.
With Microsoft cooperating to improve
the language, now we can move on beyond the Fifth Edition, toward
ECMAScript harmony.
We want to add some more conveniences
to facilitate more programming for the large projects. To allow
people to have some guarantees that when they assemble large
JavaScript projects in the field, it will work.
Right now, it has to check all its
arguments and any possible value coming in. If there were a better
way to enforce the API constraints and conventions and there's not
some middle man taking the blame wrongly, then developers would have
better time bringing these large scale JavaScript projects up.
At the Oslo ECMA meeting, a lot of the
controversy went away, if you excluded a few things in the Fourth Edition. We excluded a few, like namespaces and packages. We ended up
finding the common ground. We could see the light at the end of the
tunnel toward this goal of harmony, based on some new syntax, better
strict mode, some kind of API contract checking. An improved system
for programming which doesn't require you to write so much functional
code.
Think about Google's Web Toolkit. You
can see people benefiting from, in that case Java, which is not the
kind of language we're gonna evolve towards. But the extra steps you
can do with a tool to help you add power. We see a future where
JavaScript will have some extra muscle.
We're consolidating what's common into
the spec so it can be baked into the next engine. That's the proper
role of standards.