I was looking at Mozilla Developer Documentation on Javascript. Is it Mozilla's interpretation of the ECMAScript standard or is it documenting how they have implemented Javascript in Firefox?
Basically, I want to know whether their documentation is valid across all browsers or just Firefox.
It's both, basically. From JavaScript/Reference/About:
The JavaScript Reference serves as a repository of facts about the
JavaScript language. The entire language is described here in detail. […]
Recent versions of Mozilla-based browsers support newer versions of
JavaScript. […]
Browsers that do not support at least JavaScript 1.5 are very rare
today, since JavaScript 1.5 was introduced back in 1999. If you're
interested in historic information, please refer to the Wikipedia
article on ECMAScript.
JavaScript documentation of core language features (pure ECMAScript,
for the most part) [consists of the Guide and the Reference].
It is definitely a reference about the Mozilla implementation(s) of JavaScript, which today covers all of EcmaScript 5.1 features. They're well documented, also containing information about bugs in older Mozilla implementations and in relevant other engines. Each article also lists cross-browser support in a table, though these are sometimes not correct and/or exhaustive.
The reference also includes documentation of proprietary Mozilla features and of their draft implementations for upcoming standards. These are properly marked as such, usually with the non-standard-tag.
Also, don't forget that it's a wiki!
as Alex K has said in his comment
It documents Geko, the mozilla implementation of JS which also includes all the non-standard functionality they have included
It is also an excellent reference for standard js api calls, but should always be used with a slight caveat of, it is the Geko implementation so may not behave as described, but generally it does in my PERSONAL experience
Related
When you crate a new Google Apps Script, it seems to support the v8 runtime by default. The documentation states:
Apps Script supports two JavaScript runtimes: the modern V8 runtime and an older one powered by Mozilla's Rhino JavaScript interpreter.
The V8 runtime supports modern ECMAScript syntax and features.
The V8 runtime documentation states:
You can use modern ECMAScript syntax in scripts that are powered by the V8 runtime. This syntax includes let, const, and many other popular features.
In both cases, they are very vague as to which ECMAScript version is supported, simply stating "modern ECMAScript syntax". This is problematic because there are 7 versions that were released between 2015 and 2021. Thus "modern" could refer to any one of these versions.
For example, I could easily assume that "modern" refers to the latest, 12th edition (2022) of ECMAScript, and end up writing code like this:
let a = 1_000;
However, attempting to use that syntax leads to the error:
Syntax error: ParseError: Unexpected token ILLEGAL line: ...
Rather than manually go through each of the remaining 6 versions until I find the latest one supported, it would be great to find documentation that explicitly states which ECMAScript version is supported.
Note: The previous related question (Which Edition of ECMA-262 Does Google Apps Script Support?) is not helpful since those answers also refer to "modern ECMAScript" rather than a definitive, specific version.
Which version of ECMAScript is supported by the V8 runtime?
There is some nuance here:
Which version of V8 does Google Apps Script use?
A reasonably recent version, and it gets updated every so often. I believe the idea is to track or slightly lag behind stable Chrome releases, but (as with any large project updating its dependencies) there may occasionally be hiccups/delays. Right now it should be somewhere in the 9.x version range. (For future readers: I expect this statement to be outdated before 2022 is over!)
Which version of ECMAScript does the Google Apps Script V8 Runtime Support?
I suppose if there was a simple answer to this, you'd find that in the documentation. As #Kaiido said in comments, JavaScript engines implement new JavaScript features one by one (rather than EcmaScript versions). So, for browsers just like for environments like GAS, it usually makes more sense to ask "is feature X supported?", because it may well be that some, say, ES2020 features are still missing but some ES2021 features are already available.
Why does let a = 1_000; produce a Syntax Error?
Well, the V8 version that GAS uses is sufficiently new (by at least two years) to support it; but the overall GAS experience depends on more than V8: the editor is parsing the entered source in order to provide help or highlighting or error checking or whatnot. It looks like the GAS team is aware that certain features aren't supported yet by the components responsible for that, and is actively working to remedy that. (I have no idea what the timeline is.)
Why does let a = 1_000; produce a Syntax Error?
Just to expand on #jmrk's answer about new features not supported by the parser.
function test2564(){
//let a = 1_000; throws syntax error by the parser
console.info(eval(`1_000`));// correctly logs 1000
}
The underlying V8 engine is good and supports the latest features, but the parser won't allow you to save or execute the project with those features, as it considers them as syntax errors.
I just tried in Firebug console,
let (X=10) X/2
and
[x,y]=[y,x]
These are features supported by SpiderMonkey, I guess V8 has its own share.
Where can I learn of features that are not yet included in ECMAScript, but work in various browsers? Is there a place where these are collected together?
ECMAScript 6 (a.k.a. ECMAScript 2015) is the current standard for JavaScript, but engines have yet to implement it completely:
Table showing what ES6 features are supported where: http://kangax.github.io/compat-table/es6/
Three books on ES6 that are free to read online (buy them I you like them!):
Read Understanding ECMAScript 6
Exploring ES6
JavaScript Allongé, the "Six" Edition
ES6 in bullet lists
Starting with ECMAScript 2016, there will be yearly releases and a new release process:
Blog post explaining the new release process and the features that are candidates for ES2016: http://www.2ality.com/2015/11/tc39-process.html
Official list of proposed features (that may or may not be accepted for the ECMAScript standard): https://github.com/tc39/ecma262
Feature table for ES2016: http://kangax.github.io/compat-table/es7/
If you want to use any of the new features even on older engines, you can transpile them to ES5 via Babel: https://babeljs.io/
And here is a article covering various resources around Harmony/ES6/Javascript.next:
http://addyosmani.com/blog/ecmascript-6-resources-for-the-curious-javascripter/
That first feature is known as a "let expression" and it is nonstandard; it was dropped from Firefox 41, and the similarly nonstandard "let block" was dropped from Firefox 44: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Non-standard_let_extensions
I was surprised to find that this particular non-standard JS was not mentioned in Kangax's table, but I guess he had to restrict this list to non-standard JS extensions that are supported by multiple engines: https://kangax.github.io/compat-table/non-standard/
If you want to go deeper down the rabbit-hole, and Kangax and MDN haven't satisfied your curiosity, this old reference may tell you about curiosities in older browsers: help.dottoro.com/ljsdaoxj.php
Beyond that, the browser-makers usually document the quirks of their own browsers (MDN is also good about documenting non-Mozilla quirks, but it's not perfect); speaking of quirks, Peter-Paul Koch documents both standard and non-standard DOM methods here: quirksmode.org/dom/
Anyway, these aren't just "not yet" in the standards, but likely "not ever" and you shouldn't use them in your own code.
For current ECMAScript 264 implementation here is a list of features supported by different browser vendors:
http://kangax.github.com/es5-compat-table/
For the next generation ECMAScript Harmony some resources:
http://addyosmani.com/blog/ecmascript-6-resources-for-the-curious-javascripter/
http://kangax.github.com/es5-compat-table/es6/
Here's something I've been pondering after countless hours fixing JS to be cross-browser compatible (mostly IE): Why isn't Javascript consistent accross browsers?
I mean, why can't JS be nice like Java and Flash? Instead, we have to resort to frameworks like jQuery. Don't get me wrong, they make my life easier - but why do they even exist in the first place?
Is there a historical reason for this? Do companies rolling out browsers just ship their own JS engine? What are the politics that make standardization so difficult?
(Note: I understand that a good part of the problem is DOM related, but the question remains).
The Javascript core language for the most part is consistent ( Referring to ECMAScript version 3 released in 1999. )
It's the DOM implementations that cause headaches. Partly because at one point there was no DOM specification so browsers could do whatever the hell they wanted in terms of making up the rules for which to access and manipulate html elements in a web page.
For example:
window.addEventListener for DOM supporting browsers, while window.attachEvent for IE.
textContent for DOM supporting browsers, innerText for IE.
Memory leakage for attached event handlers in IE so you have to unload them manually
getElementById is buggy in IE and Opera because it returns elements by name
getAttribute('href') returns inconsistent values
There are also issues relating to the browser's CSS support.
IE6 doesn't support native PNGs so you are forced to use the filter library
Buggy animation in IE dealing with filter opacity
Language core inconsistencies would be things like
Inconsistencies between regex engines
But yeah, in short the point is that before, there was no standard. Since then, the w3 came up with standards, but every browser vendor has its own way of dealing with implementing it. There's no governing body that forces the vendors to fully apply the spec.
Do companies rolling out browsers just ship their own JS engine?
Yup, that's probably the main reason. There is no unified JS engine; there are various implementations of ECMAScript.
Browsers roll their own implementation, plain and simple. It's the same reason why rendering and CSS and all that are different across browsers. Java/Flash/etc. are more universal because they're abstracted out of the browser and accessed via a plugin of some sort. But their actual core implementations are separate from the browser and controlled by a single vendor.
To add to the other answers: there is a historical reason for this. I can write this myself, but quoting Wikipedia is easier on the fingers:
JavaScript was originally developed by
Brendan Eich of Netscape under the
name Mocha, which was later renamed to
LiveScript, and finally to JavaScript.
LiveScript was the official name for
the language when it first shipped in
beta releases of Netscape Navigator
2.0 in September 1995, but it was renamed JavaScript in a joint
announcement with Sun Microsystems on
December 4, 1995 when it was deployed
in the Netscape browser version 2.0B3.
[…]
JavaScript very quickly gained
widespread success as a client-side
scripting language for web pages. As a
consequence, Microsoft developed a
compatible dialect of the language,
naming it JScript to avoid trademark
issues. JScript added new date methods
to fix the non-Y2K-friendly methods in
JavaScript, which were based on
java.util.Date. JScript was included
in Internet Explorer 3.0, released in
August 1996. The dialects are
perceived to be so similar that the
terms "JavaScript" and "JScript" are
often used interchangeably. Microsoft,
however, notes dozens of ways in which
JScript is not ECMA-compliant.
In November, 1996 Netscape announced
that it had submitted JavaScript to
Ecma International for consideration
as an industry standard, and
subsequent work resulted in the
standardized version named ECMAScript.
As you can see, the standard, ECMAScript, was developed later than the original language. It's just a matter of adapting this standard in the current implementations of web browsers, that's still going on, as is the development of ECMAScript itself (e.g., see the specification of ECMAScript 5, published December 2009).
I want to know which sites can give me information on the list of JavaScript functions that are supported by IE/Firefox/Opera/Safari.
Take a look at quirksmode
and in the Compatibility Master Table
you will get a detailed listing.
Perhaps not a direct answer to this question, but never-the-less I think this is useful to know about: You can use the Sputnik JavaScript Conformance tool in Google Labs to check ECMAScript conformance in browsers:
Sputnik is a JavaScript conformance
test suite containing over 5000 tests.
It tests how well a JavaScript
implementation adheres to the ECMA-262
specification version 5, looking only
at those features that were also
present in the previous version,
version 3, and not the new features
added in version 5.
There are several sites for that but you'll probably find that none are absolutely complete, so it is worth checking out each of them
quirksmode.org compatibility tables
sitepoint JS reference (work in progress)
Mozilla MDC reference (mozilla only but worth mentioning)
This looks useful http://kangax.github.com/es5-compat-table/
The Mozilla Foundation continues to add new language features to JavaScript. They're up to version 1.8 now where 1.5 was more or less the ECMA baseline.
However, Firefox is the only browser that supports the latest version and IE is firmly stuck at a 1.5-equivalent JScript.
What purpose do the Firefox-only extensions serve? Or are they just lying dormant until (and if) the rest of the browsers catch up?
Firefox, Thunderbird, and other XUL apps also have large portions of themselves written in JavaScript. A more featureful JavaScript means a better development environment for Firefox and other Mozilla apps.
Extending the language is a good idea, even if only one browser is doing it - eventually it will prove itself and be made into the standard at which time other browsers will have to catch up.
Otherwise, how can progress be made - Microsoft does this all the time: would XMLHttpRequest have ever made it into the standards if Internet Explorer wouldn't have implemented it first?
From the Mozilla perspective the purpose of these changes, except for adding more capabilities for use by web developers, is to lead up to JavaScript 2.0, that is being developed as the next revision of ECMA 262 (revision 4) TC39 workgroup.
Future browsers will support JavaScript 2.0. In the mean time, developers are invited to take advantage of these extra features - natively in Firefox and using JavaScript libraries that provide backward compatibility with Internet Explorer. I find this very useful.
Also, it may be interesting to note that Webkit (the engine developed by KDE and used by Safari, Chrome and several free software browsers) supports JavaScript 1.7.
The biggest reason at the moment for improved JavaScript is for extension writers, who need not worry about cross-browser compatiblity.
JavaScript is a trademark by Sun which was licensed to Netscape and is now held by the Mozilla Foundation. Microsoft has their own implementation of the language called JScript, but there are others (eg. DMDScript).
ECMAScript was an afterthought to add a common baseline to the various implementations. So it's only natural that language development continues outside the standards committee, which is free to add the changes pioneered by the implementors in future revisions of the standard (eg the array extras introduces in JS1.6 will be in ES3.1).