Is there a way to alert the supported EcmaScript version of the current environment where I run my JavaScript?
Short answer: No.
Long answer: First of all, browsers doesn't implement ECMAScript but a language based on that specification (e.g. JavaScript for Firefox, JScript for Microsoft). Often, they can implement part of the standard, and complete the standard in a next version of the language (it happened in JavaScript 1.8 / 1.8.1 / 1.8.5 about ES5 for example, see New in JavaScript).
Plus, they could anticipate the standard: see for...of or let, that Mozilla has since years, that are part of ES6.
So, you can't really say what ES version is supported by your environment; what you can do is testing the functionality you are interested in, and use them. In most of the case, we apply a shim, where is possible, to emulate that functionality, like for ES5.
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.
This question already has answers here:
What is TypeScript and why would I use it in place of JavaScript? [closed]
(5 answers)
Closed 6 years ago.
Judging by the ES6 compatibility table foundhere
Most shims and transpilers only implement below 70% of ES6 features, so why should someone use Babel/Traceur when Javascript ES6 is pretty much supported now in Chrome/Safari and Firefox by default.
I mean, if I was a developer at say Babel - surely it would be your number 1 priority to make sure you have ES6 and even ES7 features implemented before your competition.
Or am I missing something here?
Most shims and transpilers only implement below 70% of ES6 features, so why should someone use Babel/Traceur when Javascript ES6 is pretty much supported now in Chrome/Safari and Firefox by default.
Because some of my applications still need to support down to IE9 (we finally got your client to raise the bar to IE9). And it's not because of the lack of knowledge due to our client, it's because the users of that platform actually use this Browser.
Especially when your users are companies (or their employees) IE (not even Edge) is often still the standard.
"am I missing something here?" -Yes. You are missing decades of arguments about the relative merits of dynamic and static typing. Get to reading. – Jared Smith
#Daniel, none of your edits does change anything at this point made by Jared.
JS will probably never provide static type checking or compile time errors; because this is a substantially different approach to writing and publishing code.
I mean, if I was a developer at say Babel - surely it would be your number 1 priority to make sure you have ES6 and even ES7 features implemented before your competition.
Yes, I like using ES6 and use a transpiler when I need to, but I still consider ES7 features as unstable and work in progress. If the final implementation will differ from the current version I'd have to revisit and check every project I would have used it on. That's too much uncertainty to actually use them in production, so ...
I (as one of Babels's users) actually don't care wether one transpiler or the other already supports these latest features, unless there's a final standard published.
Although sometimes I like playing around with these new features and take like to take a look at their benefits, possibilities, limits and problems, and how to transpile them into current code.
In general, transpilers exist to convert code written for one environment to code written for a different environment. This can be done for converting code between entirely different languages, or merely between different versions of a language.
So early on when ECMAScript 6 was new and the browsers didn't support much or any of it, there were transpilers developed to let you use ECMAScript's new language features in browsers that only supported the "legacy" ECMAScript features.
Even though the newest browsers now support most or all of the new features, little has changed. You'd still use a transpiler to support those same previous implementations that didn't support those features.
At some point, a developer may drop support for certain browsers, which would mean that at that point they could stop transpiling the code. This decision is going to be made differently by different individuals, and so the transpilers will continue to be used for years to come.
I don't understand the best way to use "let" keyword...
In IE11 and Chrome45 I can use it fine
In Safari8.0.4, like in older versions of Chrome, it gives the error "unexpected use of reserved word 'let'"
In Firefox the let keyword only works inside <script type="application/javascript;version=1.7"/>, but this script type isn't even recognized as Javascript in IE11, Chrome45, Safari8.
Here's a JSFiddle that shows it in action: https://jsfiddle.net/p6cgtyg6/1/
So -- I don't mind requiring users to use modern versions of their browsers.
And I don't mind excluding Safari if there honestly is no version of Safari that supports this keyword. (Is that really true? Why does everyone spend all their time griping about IE when Safari seems so much worse in ES6 terms? Have I missed something?).
But how should I allow "let" to work in Firefox while not preventing Chrome/IE? (I haven't yet found links from people griping about how Firefox script tag behaves differently from Chrome, and I'd have expected more complaints, so I figure I must have missed something obvious...)
Concerning Safari 8, it's just not supported ; for that browser, I'd recommend using Babel.
If you have the gut feeling that this bug won't be fixed anytime soon* then you could have a script that detect Firefox which would then inject your script(s) with the appropriate value for the type attribute.
As a side note, I would advise not to use let blocks—unless you wanna use this transpiler—nor let expressions which will be dropped.
* fixed in Firefox 44
let is a part of ECMAScript 6 specification, and ECMAScript 6 itself is in 'draft' status. Even in its incomplete form its features aren't supported fully by actual browser versions.
Since you want to dive into ES6 today for production, your best bet is to use ES6 to ES5 transpiler, most prominent ones are Babel and Traceur, which are available as both CLI and packages for the build system of your choice. There are online tools for Babel and Traceur to try them out. And Scratch JS extension for Chrome uses both Babel and Traceur and is excellent for developing and compiling ES6 scripts if the build system is not an option.
Here is up-to-date comparison table that embraces ES6 feature support in both browsers and ES6 compilers.
And here is a great collection of ES6-related tools.
See browser compatability of this ES6 keyword.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let#Browser_compatibility
Also see this SO post for ES6 feature detection.
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/
https://developer.mozilla.org/en/New_in_JavaScript_1.7
A lot of these new features are borrowed from Python, and would allow the creation of less verbose apps, which is always a good thing. How many times have you typed
for (i = 0; i < arr.length; i++) {
/* ... */
}
for really simple operations? Wouldn't this be easier:
[/* ... */ for each (i in arr)]
I think brevity is a great thing. Basically, it all comes down to IE in the end, though.
Does IE support these new features? What about other browsers?
While this question is a bit old, and is marked "answered" - I found it on Google and the answers given are possibly inaccurate, or if not, definitely incomplete.
It's very important to note that Javascript is NOT A STANDARD. Ken correctly mentioned that ECMAScript is the cross-browser standard that all browsers aim to comply with, but what he didn't clarify is that Javascript is NOT ECMAScript.
To say Javascript "implements" ECMAScript means that Javascript includes ECMAScript, plus it's own proprietary extra non-cross-browser features. The for each example given by nicholas is an example of a proprietary feature added by Mozilla that is not in any standard, and therefore unlikely to be adopted by any other browsers.
Javascript 1.7 and 1.8 features are useful for extension development in XUL, but should never be used for cross-browser development - that's what standards are for.
No, when they say "JavaScript", they mean it literally: the ECMAScript engine used by Gecko. JScript and other engines (AFAIK) don't support these features.
EDIT: According to wikipedia, JavaScript 1.7 implements ECMAScript "Edition 3 plus all JavaScript 1.6 enhancements, plus Pythonic generators and array comprehensions ([a*a for (a in iter)]), block scope with let, destructuring assignment (var [a,b]=[1,2])". So these features are not part of ECMAScript.
In addition to IE not supporting it, it seems like the webkit based browsers (Safari, Chrome), despite claiming to have JS 1.7 support (actually executing script tags declared as being in JS 1.7), do not actually support any of these features which means that for now, JS 1.7 with its very nice features is limited to Geko browsers alone.
And because Webkit still executes scripts tagged as 1.7 only, this also means that we can't even fail gracefully but we'll just produce syntax errors on these browsers when we are using any of the new keywords or syntax.