5

Long Question

To start, I know ECMA Script is the standard, and JavaScript and JScript are implementations. I understand that all three have their own specifications maintained, and there are many, many engines, interpreters, and implementations, but my specific question is:

Assuming the implementation of a perfect interpreter and engine for each of the three, what could you do in one that you could not do in another, or what would have different effects in one than the other two?

I understand it's a broad question, but as both languages (JScript & JavaScript) are derived from the specification (ECMAScript), the practical differences should be negligible.

Again, I'm not talking about cross-browser compatibility (IE8 & IE9 used different engines that interepreted JScript differently, and standards have changed over time), but pure ECMA5, JavaScript (if there is an official standard, I guess the closest is W3C or maybe MDN, and JScript (which is apparently maintained at MSDN (go figure)).

Notes:

This is not a duplicate of this question which is five years out of date, and deals with the definition of the terms, not the applications of the languages, or this question which again explains that JavaScript and JScript are dialects of ECMAScript, but does not go into any functional differences.

This question is closest, but specifically what I'm after are technical pitfalls a developer expecting X and getting Y should be wary of. A good example would be from this question where the following code:

// just normal, casual null hanging out in the sun
var nullA = null;
// query for non existing element, should get null, same behaviour also for getElementById
var nullB = document.querySelector('asdfasfdf');

// they are equal
console.log(nullA === nullB);

// false
nullA instanceof Object;

// will throw 'Object expected' error in ie8. Black magic
nullB instanceof Object;

showed a difference in implementations of JScript, that did not in theory comply with ECMA Standards.

Community
  • 1
  • 1
Jason Nichols
  • 3,739
  • 3
  • 29
  • 49
  • 1
    Since you are asking a hypothetical question: `Assuming the implementation of a perfect interpreter and engine for each of the three, what could you do in one that you could not do in another, or what would have different effects in one than the other two?` I doubt you'll get any real definitive answers since it is impossible to test since the perfect system to interpret `JScript` and `JavaScript` doesn't exist. – abc123 Sep 13 '13 at 19:06
  • *Assuming the implementation of a perfect interpreter and engine for each of the three*, as you say, there should be no differences in the core language. Any implementation is free to make additions though, provided they are in accordance to the specification. – bfavaretto Sep 13 '13 at 19:07
  • Are there interpreters that are fully compliant with any of the specs? I imagine FireFox and IE* are compliant with the languages they maintain. – Jason Nichols Sep 13 '13 at 19:08
  • JScript was just a name MS gave to their implementation of ECMAScript because they were afraid of trademark issues[[1](http://en.wikipedia.org/wiki/Jscript#Comparison_to_JavaScript)]. From what I can tell, MS has practically dropped the name in recent years and just started using the name "JavaScript" for their implementation. http://msdn.microsoft.com/en-us/library/ie/yek4tbz0(v=vs.94).aspx – Nathan Wall Sep 14 '13 at 05:25

2 Answers2

8

A implementation of the EMCAScript standard is more than code that brings the specification rules to life. The ECMAScript standard is deliberately incomplete:

Each Web browser and server that supports ECMAScript supplies its own host environment, completing the ECMAScript execution environment.

An ECMAScript implementation must supply a "host environment". In the case of a Web browser, that host environment includes DOM manipulation APIs and other APIs specified by the W3C and WHATWG. The behaviors of (indeed, the existence of) these APIs are not specified by ECMAScript.

Objects used to complete the "host environment" of an implementation are called "host objects". Host objects are not bound to follow normal object rules: they may throw errors for property access that would be valid on a native (non-host) object, or they might allow certain actions that would be natively disallowed.

JScript and JavaScript might implement their DOM APIs differently. Which implementation is "correct" on some particular point is not a matter of ECMAScript compliance, but rather a matter of compliance with W3C standards. Even if a DOM object seems to exhibit some behavior that runs contrary to "normal" ECMAScript behaviors (like your instanceof error example), it's still legal ECMAScript according to section 8.6.2:

Host objects may support these internal properties with any implementation-dependent behaviour as long as it is consistent with the specific host object restrictions stated in this document.

"Internal properties" here include logical operations like "getting the value of an object's property by name", codified as [[Get]]. A host object's custom [[Get]] implementation might throw an error, or ignore a previously-set property.

API differences are distinct from actual language differences. A language difference suggests a difference either in supported lexical grammar or in the behavior of native (non-host) objects. Some differences in actual language include:

  • JScript allows for cc_on comments that cause conditional compilation
  • Mozilla's JavaScript supports the yield keyword, and generators, and a bunch of other stuff that is not in the ES5 spec (but likely will be in ES6)

  • All browsers support function declarations in blocks, which is not legal ECMAScript syntax:

    function foo() {
    bar();

    if(condition) {
        function bar() { } // this is not legal
    }
}

    Browsers that support this (i.e., all of 'em) are extending the ECMAScript language. Also, JScript will hoist bar in that example, while Mozilla's JavaScript will not. This is because the two browsers have extended the ECMAScript language in incompatible ways.

apsillers
  • 112,806
  • 17
  • 235
  • 239
  • awesome, this is the type of stuff I wanted to know about. Thanks, @apsillers – Jason Nichols Sep 13 '13 at 19:18
  • 1
    Another common extension is `__proto__`, also implemented by all browsers. It would be interesting if this answer could one day become an exhaustive list of the differences, although I'm not sure if that's viable or maintainable... – bfavaretto Sep 13 '13 at 19:27
  • @bfavaretto that was kind of my hope. That way there'd be a go to point for programmers with a list of what the practical differences would be. Like function hoisting differences in JScript v. JavaScript, and function blocks being not ECMA. – Jason Nichols Sep 13 '13 at 19:48
  • apsillers, the `instanceOf` issue is IMHO a violation of 4.3.8 as they do not inherit properly from `null` or `Object` which is required of all host objects – Jason Nichols Sep 13 '13 at 19:50
  • 1
    @JasonNichols You're thinking of [8.6.2](http://www.ecma-international.org/ecma-262/5.1/#sec-8.6.2), but, yes, that appears to be correct: the problem probably occurs in [`[[HasInstance]]`](http://www.ecma-international.org/ecma-262/5.1/#sec-15.3.5.3) step 4(a), which causes the engine to attempt to get `[[Prototype]]` of a non-object (because the previous `V` has a non-object prototype), where 8.6.2 has required an object. – apsillers Sep 13 '13 at 20:42
  • appreciate the clarification, @apsillers. Will update my answer to that question accordingly. – Jason Nichols Sep 13 '13 at 20:43
0

From here you can download a .zip of .pdfs that contains documents (MS-ES[35](EX)?.pdf) that deal with the standards (3/5) and Microsoft's extensions to them.

Ekkehard.Horner
  • 38,498
  • 2
  • 45
  • 96