What are the functional differences between JScript, JavaScript, and ECMA Script?

Question

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.

Answer 1

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.