December 17th, 2007
I've just completed my first survey of the current ECMAScript 4 implementations. I went through and attempted to compile as many bugs and features as possible, as stated by the ECMAScript 4 specification and double-check them against all the actively-maintained implementations. You can view a nice overview below.
I think it's fascinating to note that there's 3 implementations that already have over 25% of all the new features in the language implemented.
View: The raw data
About the implementations:
ECMAScript 4 Reference Implementation (ES4 RI)
This is the reference implementation provided by the ECMA technical group, as a reference for those creating their own implementations.
Tamarin
Tamarin is the joint effort of Mozilla and Adobe to adapt the Open Source Adobe Virtual Machine to match ECMAScript 4 - and run in Firefox 3.next() (via ActionMonkey) and Flash 10.
Update from Tom:
Tamarin VM by itself doesn't directly support ECMAScript source code. Rather, the subproject esc (written in ECMAScript 4) compiles ECMAScript 4 to abc bytecode that is run by the Tamarin VM.
Spidermonkey
Spidermonkey is the JavaScript engine currently in Firefox (and other Mozilla-based projects). It's being actively updated with new features to match the ES4 specification. This project will, most likely, be superseded by ActionMonkey.
Rhino
Rhino is a Java implementation of JavaScript which is currently being updated to meet the ECMAScript 4 specification.
Futhark (Opera)
Futhark is the JavaScript engine that is a part of Opera 9.5 (Kestrel) and will be a part of Opera 10 (Peregrine). It's being actively updated to match the ECMAScript 4 specification.
Mbedthis
Mbedthis has used Javascript as a web scripting language in its AppWeb embedded web server product for several years. More recently, they have been updating the language for use in mobile devices and has developed a C and Java VM for hosting Javascript widget style applications to run in standard features phones. They are tracking ES4 and are upgrading their implementation as the spec is finalized. They are planning to release a test version late Q1 2008 that will implement most of the planned features in ES4. This will be dual license: open source and commercial.
Tags: ecmascript, javascript, ecmascript4, javascript2
15 Comments on 'State of ECMAScript 4 (Dec '07)'
October 31st, 2007
As the the ECMAScript 4 (JavaScript 2) specification comes closer to its final form, a number of aspects have, already, congealed and able to be disseminated and learned. Specifically, the bug fixes to ECMAScript 3 that are being included in ECMAScript 4 are quite refined at this point.
The bug fixes to JavaScript came from a number of places. Generally, however, they have come about due to aspects being under-specified, causing confusion to occur amongst language implementors.
Additionally, bug fixes have come about from universal conventions that have been adopted by implementors causing them to be ported back into the specification.
A full list of the bug fixes can be found on the ECMAScript 4 wiki.
You'll, generally, find that a number of these fixes are already included in some browser implementations (generally more-so in Spidermonkey-based ones, than others). However, a couple of these are implemented in no browser, at this point (like this propagation) and still others are implemented in all browsers (like single character substrings).
More than anything else, however, these changes represent an attempt to bring greater levels of common-use compatibility to the language (allowing more web pages to work) and bringing backwards compatibility inline with ECMAScript 3 implementations, rather than with the specification.
Generally, you should use this as a guide of what's to come, not as of what you can universally use, right now.
arguments is now a 'real array'
arguments is now a 'real array', as opposed to an array-like object, with the following distinctions:
arguments.toString() behaves like an object's .toString(), rather than an array's.- If you manipulate the
.length property its contents aren't deleted (if the length is reduced), nor are new items added (if the length is increased).
This means that you can now do simple things like:
arguments.slice(1);
Whereas, previously, you would have to do:
Array.prototype.slice.call( arguments, 1 );
typeof /regexp/ == 'object'
This change makes it such that callable objects return a typeof of 'object' rather than of 'function'.
The result of this fix is best exhibited by an uncommon feature in Spidermonkey that's caused a lot of confusion. Many don't know this, but you can do this with a regular expression (in Firefox, et. al.):
/test/('test')
// is equivalent to:
/test/.exec('test')
In this case, a regular expression is an object that is also callable (thus the typeof was actually 'function' rather than 'object'). So while fixing typeof of a RegExp, in Spidermonkey, isn't a true ECMScript 4 bug fix, it's indicative of the larger problem being solved. In reality, most users expect the typeof value to be 'object' in this case. The adjustment is that callable non-functions now have a typeof of 'object', allowing this to behave as one would expect:
typeof /regexp/ == 'object'
this propagation
If you now define a function inside another, its this is bound to the this of the outer function, as opposed to the global object (e.g. window).
This makes the following code possible:
function User(name){
this.name = name;
function test(){
alert(this.name);
}
test();
}
Whereas, previously, you would've had to have used a closure to store a reference to this and retrieve it within test(). The resulting code would have looked something like this:
function User(name){
var self = this;
this.name = name;
function test(){
alert(self.name);
}
test();
}
undefined, NaN and Infinity
undefined, NaN and Infinity are now immutable global properties. Some implementations already took some of these into account, but now it's being standardized.
Thus you can do:
1/0 == Infinity
1/'foo' == NaN
RegExp Reconstruction
/regexp/ creates a new, unique, object every time it's evaluated. For example, the following evaluated to true, previously, even though it shouldn't have:
var test = [];
for ( var i = 0; i < 2; i++ )
test.push( /test/ );
test[0] == test[1]
>> true
This now brings RegExp literals in line with all other literals (as to how they are evaluated). This bug led a number of people astray - and in the end it was the third most duplicated JavaScript bugs.
Trailing Commas
When initialising an object, trailing commas are ignored (some implementations already support this).
var obj = {
a: 1,
b: 2,
};
It's now being made expressly clear that a trailing comma in an array initialisation does not create an extra undefined entry at the end of the array. JScript currently gets this implementation detail wrong, even though it was specified in ECMAScript 3. The correct result is as follows:
[a, b,].length
>> 2 (not 3)
Single-Character Substrings
You can now get single characters out of a string by using [index], instead of the .charAt(index) method. This way was already widely implemented.
'string'[0]
>> 's'
Undefined Looping
You can now do a for .. in loop against an undefined object (or a null) without an exception being thrown. For example:
for ( var i in null ) {}
for ( var i in undefined ) {}
This was, originally, intended to throw an error in ECMAScript 3 but this has been reverted due to web pages coming to expect this to work.
Comparison Order
When performing a comparison of two items the order in which they were compared was not guaranteed. It is now specified that the values be retrieved in left-to-right order.
For example, this is what could have happened previously:
var a = {
valueOf: function(){
alert('a');
return 1;
}
};
var b = {
valueOf: function(){
alert('b');
return 1;
}
};
a<b
>> alert('a')
>> alert('b')
>> false
a>b
>> alert('b')
>> alert('a')
>> false
for .. in order
When looping through the properties of an object the order in which they were returned was left up to the implementation - now it's required that the properties be returned in the order in which they were created. The final result would allow for the following, intuitive, result:
var obj = {1: 2, p: 'hi', '_':'under'};
for ( var i in obj )
alert(i);
>> alert('1')
>> alert('p')
>> alert('_')
Implementations since JavaScript 1 have generally done it this way (and implementations that haven't have found that web pages generally require this convention). Thus, it's being made expressly clear now that this is the case.
Tags: javascript2, ecmascript, mozilla, javascript
16 Comments on 'Bug Fixes in JavaScript 2'
October 31st, 2007
I'm currently in Tokyo, getting ready to give a couple presentations on JavaScript 2/ECMAScript 4/ActionScript 4. It should be a lot of fun - this will probably be the first time that a lot of people hear about these language changes so I'm interested in getting some feedback. (I'll be posting my "Future of JavaScript" slides from last week's Ajax Experience conference, shortly.)
Specifically, I'll be speaking at the following two events:
Adobe Max Japan
I'm going to be giving a talk on Tamarin and ECMAScript 4 (which will be the next version of ActionScript). You can spot me on the speaker list as well.
The Adobe community is just as interested in seeing the progression of the ECMAScript language as JavaScript developers are (as they are, now, inherently bound going forward). I'll be curious to hear what sort of questions or concerns arise, especially considering that they've had ActionScript 3 (which is, sort of, halfway between ES 3 and 4) to play with for for quite some time now.
This will be another talk (presented, primarily, to the Shibuya.JS user group - in conjunction with Mozilla Japan). You can see Shibuya.JS' thoughts on the talk here. This event has already sold out - but I'm looking forward to meeting everyone who's coming!
As a side note: Shibuya.JS is the only JavaScript user group that I know about - really anywhere in the world. Looking through some of their lightning talks just goes to show how committed they are to talking about cool JavaScript code. For example, here's a presentation that was given on jQuery. While they glance over the fundamentals of the library, they immediately roll back the cover and look at the most interesting code contained within it (crazy hacks, i18n regexps, etc.) - I was very impressed. I'm definitely looking forward to speaking with them some more.
Tags: actionscript, mozilla, tokyo, javascript, ecmascript, javascript2
2 Comments on 'Speaking in Tokyo'
