Freigeben über

ECMAScript 3 and beyond

  • Artikel

The web has become the primary global computing platform tying together hundreds of millions of sites. In the eight years since the release of the ECMAScript Language Specification 3rd Edition (ES3), ECMAScript (commonly known as JavaScript™ or JScript ™) has grown in importance as one of the key technologies of the web.

The specification of ECMAScript has been stable for eight years. In many ways, this stability was probably an essential enabler for the emergence and broad adoption of Ajax technologies. However, today’s ES3 standard does not capture all the de facto compatibility conventions reached by eight years of this stability - the compatibility so essential to the success of rich web applications. For rich web applications to be successful, JavaScript must function identically on all browsers. The developer of a JavaScript-based web application does not get to choose what implementation will run their application; the user implicitly chooses that when they choose their preferred browser. Strong implementation conformance, then, across browser-based implementations is fundamental.

Let me give you a few examples of the lack of such conformance:

Did you know that Custom properties that shadow [[DontEnum]] properties on Object.prototype are not enumerated using for-in in IE? Consequently, it is not possible to transfer them from one object to another using for-in. Consider the following script where toString is shadowed on cowboy.

<script>

function cowboy() {

  this.toString = function () { return "cowboy"; }

  this.shoot = function () { return "bang!"; }

}

var p = new cowboy();

document.write("Enumerable properties:");

for (var i in p) {

  document.write(" ", i);

}

var res = p.propertyIsEnumerable("toString");

document.write("<br/>propertyIsEnumerable(\"toString\"): ", res);

res = p.hasOwnProperty("toString")

document.write("<br/>hasOwnProperty(\"toString\"): ", res);

</script>

How about the case where FireFox implements additional properties (and that could cause unexpected results)?

<script>

var x = {};

x.__proto__ = 3;

document.write(x.__proto__);

</script>

Try these on your browser and see what happens.

The point is that JavaScript developers shouldn’t have to detect and workaround such issues. JavaScript should work the same across all implementations. We believe this is the first step in making JavaScript better.

To make it possible to achieve such implementation conformance, the first step is knowing where the divergences are. We in the JScript team are looking into where various browser based implementations diverge, where our engine is incorrect in its interpretation of the specification, what if any de facto compatibility conventions have been reached, and the value of codifying such conventions into the standard. We’ve published the first draft of JScript Deviations from ES3 as a starting point.

In upcoming posts I will touch briefly on issues that we are looking at keenly and that we hope will make the life of the web programmer easier. If you would like some specific topic covered, please do let us know.

- Pratap Lakshman, JScript

Comments

  • Anonymous
    October 29, 2007
    The comment has been removed

  • Anonymous
    October 30, 2007
    There have been a number of blog posts recently about JavaScript developments, e.g. Gabriele Renzi’s

  • Anonymous
    October 30, 2007
    Just to set things straight: JavaScript and JScript are both ECMAScript /implementations/. JavaScript is being maintained by the Mozilla Foundation, JScript by Microsoft. The example given here with respect to for-in is a JScript behaviour and has nothing to do with JavaScript. If you think that JScript's behaviour is better in this respect than JavaScript's behaviour, or if you think that Firefox' behaviour with respect to the special JavaScript proto property is incorrect I suggest you take it up with the Mozilla Foundation and/or Brendan Eich. The mere suggestion that JScript's behaviour in these cases should be considered the de-facto standard is preposterous. And what about these: 'bar'[1] // should yield 'a' 'bar'.substr(-2) // should yield 'ar' stop lying, start fixing!

  • Anonymous
    October 30, 2007
    And another one: /./.test('r') IE: true Firefox: false Opera: false Safari: true

  • Anonymous
    October 31, 2007
    Tino:  I think you misunderstood what Pratap way saying about de-facto standards.  The fact that JScript does something a certain way certainly does not make that a de-facto standard.  However, if all of the major browsers do something the same way, even if what they do is contrary to the actual standard specification, then that common behavior is in fact a de-facto standard.  Understanding where such de-facto agree exists is an important part of standards evolution. When there are differences among implementations as in the example in your second comment.  Then that is a place where the standard may need to be clarified. Allen Wirfs-Brock Microsoft

  • Anonymous
    October 31, 2007
    Garrett, Thank you for pointing out some additional items which we will verify and then incorporate into our document. This sort of feedback is appreciated and is what we were looking for; if you know of other items that you believe should be included please let us know. This is not just about "bugs" though. It is about understanding the de facto standard for ECMAScript. In the case of JScript, some of the deviations from the ECMAScript specification are true bugs while others are differences in interpretation of the specification. A whole section in the document is devoted to items that the specification explicitly left undefined. That said, it really doesn’t matter what category an item falls into; if programs depend upon identical behaviour in all browsers it becomes a compatibility issue going forward. The emergence of Ajax has certainly increased Microsoft’s appreciation of the importance of ECMAScript on the web and we are investing accordingly. Ajax has raised the compatiblity-bar for ECMAScript and our own services and frameworks would benefit from the existance of such compatibility. I am not claiming that JScript is the de facto standard. All I am saying is that before we can hope to improve compatiblity/interoperability among browsers it is essential to understand what has actually been implemented and what de facto agreements exist among the various browser implementations.

  • Pratap Lakshman, JScript

  • Anonymous
    October 31, 2007
    Tino, Indeed, as your second comment shows, yet another case where the observable behaviour between various implementations differ. Thank you for pointing it out.

  • Anonymous
    October 31, 2007
    The comment has been removed

  • Anonymous
    October 31, 2007
    If de facto standards and the actual ES3 spec overlap and differ, please choose the ES3 specifications. The other browser makers will catch up. If de facto standards and the proposed ES4 spec differ please choose the ES4 spec.

  • Anonymous
    October 31, 2007
    EDF, The specification being "stable" for eight years means that it has not changed in eight years.  It does refers to the specification (EMCAScript), not the implementations (JavaScript and JScript). Other than that, I fail to see how the stability of the specification had much to do with the emergence of AJAX technologies.  XMLHttpRequest is not a part of ECMAScript. Tim

  • Anonymous
    November 01, 2007
    another way to go, in order to have the best JS implementation is to concentrate in one engine, no ?

  • Anonymous
    November 01, 2007
    The comment has been removed

  • Anonymous
    November 01, 2007
    The comment has been removed

  • Anonymous
    November 01, 2007
    The comment has been removed

  • Anonymous
    November 01, 2007
    The comment has been removed

  • Anonymous
    November 01, 2007
    The comment has been removed

  • Anonymous
    November 01, 2007
    Pratap, That document is very helpful information. However, I believe you have the cart before the horse here. Specifically, many of the items in that document (e.g, items 2.3, 2.5, 2.6, et al) are not variant interpretations, but demonstrable incompatibilities with EcmaScript. Also, technically speaking, the "extension" objects like ActiveXObject, FileSystemObject, and (why'd you miss this one -- it's the only MS extension which has actually proved useful?) XMLHTTPRequest are NOT EcmaScript compatibility issues, but host Object-Model compatibility issues. Step One should be to fix demonstrable incompatibilites, then to move on to the gray areas of interpretation. @anon: the issues you mentioned relate more to DOM-compatibility rather than EcmaScript.

  • Anonymous
    November 01, 2007
    Hello Microsoft JScript team and Mr Lakshman, I went (skimmed) over the jscriptdeviationsfromes3.pdf document. It's depressing to see how many differences, incompatibilities there are between major browsers. One that is not mentioned in the document. Error object name are often not the same in browsers. When I do a try..catch..finally block and inspect the error object, I am absolutely convinced that an undefined variable should be reported as a ReferenceError, not as a TypeError. The Javascript Bible 4th edition (D. Goodman) reports that "Unfortunately, there are some discrepancies as to the specific name supplied to this [name] property for script errors". Also, as reported by others (for many years too) but not mentioned in jscriptdeviationsfromes3.pdf, toFixed() for values comprised in the ranges {(-0.94,-0.5], [0.5,0.94)} are wrong: http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/JavaScriptToFixedSupport.html Regards, Gérard Talbot

  • Anonymous
    November 01, 2007
    Anon, those aren't JS bugs as far as I can see. They're DOM ones.

  • Anonymous
    November 01, 2007
    Here's one that unnerved us in a non-browser project. Run here with WSH but bug repeatable outside that context. IIRC we tested it in rhino script engine & it worked as expected. // doesn't work; finally not processed try { throw new Error() } finally { WScript.Echo('here, in #finally#') } // does; note dummy try/finally around it try{ try { throw new Error() } finally { WScript.Echo('here, in #finally#') } } finally {} I strongly suspect MS knew about it for a long time. Thanks loads.

  • Anonymous
    November 01, 2007
    While we're at it, dismissing bugs as DOM ones and not J(ava)Script issues is just side-stepping the problem. Most of my script code has to do some DOM-ing, and if wouldn't do me much good if the ECMAScript implementations stay stable and reliable, while the DOM changes wildly from platform to platform...

  • Anonymous
    November 04, 2007
    Hello again Microsoft JScript team and Mr Lakshman, Wish list:

  • Full compliance with the ECMAScript Language Binding specified in DOM Level 1 so that HTMLElement objects can inherit from Node.prototype
  • correct (or better) error reporting (name property of Error object and message property of Error object) when exceptions are thrown
  • defineGetter and defineSetter support so that it is possible to assign functions to custom properties of HTMLElement objects http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters
  • ability to do nested clause blocks
  • Do not change how arguments are defined. arguments should not inherit from Array. arguments should inherit from Object like ES3 says. Just keep it that way.
  • Support for javascript reserved keyword const: I should be able to define constants with the reserved keyword const. http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/JSConstKeyword.html
  • comply with RFC 4329: http://www.rfc-editor.org/rfc/rfc4329.txt What is unacceptable is that Microsoft does not fix (widely known) wrong, incorrect implementations of ECMAscript in its JScript or that Microsoft takes up to more than 3, 5, 9 years to fix those. It should take a few weeks or a few months, not years. Regards, Gérard

  • Anonymous
    November 05, 2007
    Many a times, Java Script developers are perplexed by the fact that the same piece of code written by

  • Anonymous
    November 05, 2007
    The comment has been removed

  • Anonymous
    November 07, 2007
    &#xA0;&#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between Microsoft

  • Anonymous
    November 07, 2007
    &#xA0;&#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between Microsoft

  • Anonymous
    November 07, 2007
    &amp;#xA0;&amp;#xA0; In their blog, the JScript team at Microsoft is addressing incompatibilities between

  • Anonymous
    November 08, 2007
    Thanks also for posting some self-serving astroturfing links: "Kudos to the JScript team. The haters are quick to slam the IE (and by association the JScript team) for IE's incompatibilities." "It's hard to be FIRST, be innovative, and do things exactly the same as everyone else." "Credit where credit is due!" BTW did you ever get round to fixing the garbage collection so it didn't leak cycles?

  • Anonymous
    November 10, 2007
    If de facto standards and the proposed ES4 spec differ please choose the ES4 spec.

  • Anonymous
    November 12, 2007
    @EDF, @Tim: Thanks for clarifying my point. I did mean that it was the specification that was stable. @BD: Like I have said earlier, I am not claiming that JScript is the de facto standard. When I say "de facto standard" I mean those things that all widely used ECMAScript implementations do exactly the same regardless of whether or not that behaviour conforms to what is actually specified by the ECMAScript Language Specification 3rd Edition. Our document is indeed about more than the above. However, by showing where some major implementations are different or identical in their behaviours, it provides insight for understanding what the "de facto standard" actually is. And regarding your point about a "JavaScript Implementation Standards Group" - such a group already exists and is called ECMA TC39-TG1 (http://www.ecma-international.org/memento/TC39-TG1.htm). @Gérard: Thanks for sharing your wishlist.

  • Anonymous
    November 16, 2007
    Pratap, in 2.7 you wrote: IE: prints "hellohello" FF: prints “hello” followed by syntax error (bar is not defined) Opera: prints “hello” followed by ReferenceError (Reference to undefined variable: bar) Safari: prints “hello” In fact, Safari also raises a "ReferenceError: Can't find variable: bar". To see it, you need to activate the Debug menu (search for "safari windows debug menu") and choose Show JavaScript Console in that menu. I haven't finished reading the document, but it's possible that other tests were similarly affected.

  • Anonymous
    November 22, 2007
    I do hope you guys get your act together and fully implement the new Javascript proposed standard.

  • Anonymous
    January 19, 2008
    The comment has been removed

  • Anonymous
    January 19, 2008
    The comment has been removed

  • Anonymous
    January 19, 2008
    EDF, The specification being "stable" for eight years means that it has not changed in eight years.  It does refers to the specification (EMCAScript), not the implementations (JavaScript and JScript). Other than that, I fail to see how the stability of the specification had much to do with the emergence of AJAX technologies.  XMLHttpRequest is not a part of ECMAScript.

  • Anonymous
    January 19, 2008
    Thank you for pointing out some additional items which we will verify and then incorporate into our document. This sort of feedback is appreciated and is what we were looking for; if you know of other items that you believe should be included please let us know. This is not just about "bugs" though. It is about understanding the de facto standard for ECMAScript. In the case of JScript, some of the deviations from the ECMAScript specification are true bugs while others are differences in interpretation of the specification. A whole section in the document is devoted to items that the specification explicitly left undefined. That said, it really doesn’t matter what category an item falls into; if programs depend upon identical behaviour in all browsers it becomes a compatibility issue going forward. The emergence of Ajax has certainly increased Microsoft’s appreciation of the importance of ECMAScript on the web and we are investing accordingly. Ajax has raised the compatiblity-bar for ECMAScript and our own services and frameworks would benefit from the existance of such compatibility. I am not claiming that JScript is the de facto standard. All I am saying is that before we can hope to improve compatiblity/interoperability among browsers it is essential to understand what has actually been implemented and what de facto agreements exist among the various browser implementations.

  • Anonymous
    January 31, 2008
    I'm hoping someone can clear this up for me. If I have a script that is defined as; <script type="text/javascript" language="JavaScript"> //some code </script> Will IE treat this in exactly the same way as if the script had been marked as JScript or does it treat it differently?

  • Anonymous
    March 05, 2008
    Making developers more productive through the design, development, and debug phases of web application

  • Anonymous
    February 03, 2009
    The comment has been removed

  • Anonymous
    April 05, 2015
    Thanks for the post! I've been using this post as a reference as I migrate a couple of libraries to ES6 modules, with Babel targeting CommonJS and AMD. I experimented with Babel to determine if export default ... breaks on circular reference like module.exports = ... (CommonJS) and return nonObject; (AMD). Babel's CommonJS transform generates modules that handle the circular references just fine. Is this part of the spec, or is this an extension by Babel (and possibly others)?