What browsers / engines already support ES5 [strict]?
All the major browser vendors more or less have had ES5 fully implemented for a few years now (though IE 9 doesn't support strict mode). kangax created this compatibility table representing the existence of ECMAScript 5 features in major browsers and other JS implementations. It will even list the availability of those features in the browser you visit the page with. It doesn't test conformance, however.
Kris Kowal created es5-shim.js, which provides as much of the functionality of ES5 as possible to ES3 compliant implementations. Of course, not everything is possible but the goal of the shim is to allow code to gracefully degrade.
AFAIK, the only implementation of ECMAScript 5 is BESEN. It's a bit disappointing, really. BESEN was created from scratch, by a single developer, in just a couple of weeks. Google, Microsoft, Apple, Mozilla and Opera on the other hand, with all their developers, all their money, haven't been able to provide an implementation after almost 11 months. And that is despite the fact that they have dozens of developers, have an already working implementation as a base to start from, were a part of the standardization process from day one (and thus had access to the specs long before the author of BESEN did), and most of the features in the ES5 specification were taken from already existing implementations in the browsers.
AFAIK, the only two features that in ECMAScript 5 that were not already part of JavaScript were the Properties API and Strict Mode.
This page of the ecmascript wiki has links to the bugs remaining in the major implementations in progress.
Related
I have a very big doubt and it is that if ActionScript and JScript are based on ECMAScript, it is possible that they can be executed in environments like Google Chrome and if not, why not?
Any code that 100% conforms to supported versions of ECMAScript can be run in Chrome. But, you can't actually do anything useful in a browser with pure ECMAScript code because you can't interact with anything in the browser itself - instead you have to use browser-specific APIs to do that which are not ECMAScript methods, but browser-specific methods that are documented in different standards. Similarly, an ActionScript script likely interacts with its environment through non-ECMAScript methods which are not support in a browser.
And a new language that conforms to 100% to the latest version of ECMAScript would not have problems with the interpreter of each browser? I say this because every browser has a dedicated JavaScript interpreter or that's what I understand so far.
It's hard to tell what you're asking. There is no such thing as a new language that conforms to 100% of ECMAScript. That would just be an implementation of ECMAScript (not a new and different language) - just like each browser has its own implementation of ECMAScript. If it is indeed a new language, then it must have things in it that are not in ECMAScript. But, my point is that, pure ECMAScript code should run in any "compatible" ECMAScript implementation that is targeting the same ECMAScript version.
There are details of implementation that are not always complete in each browser since ECMAScript is a moving target (new revisions regularly) and the development on the implementation is ongoing work in each version. So, there can be compatibility issues around the edges of newish features, but that is true of any Javascript code running across browsers that is leverage very new features. Developers who are interested in good cross browser compatibility either stay away from the very latest features, cross compile their code to a lower common denominator using something like Babel or TypeScript or they study and test exactly what they can and can't use across all their target browsers.
After having read another similar post that doesn't answer mine, I wonder what is an easy and fast way to know if my Chrome version 68 supports JavaScript ES9 ECMAScript 2018.
There will not be a major release of ES9 in any browser. In the past it has always been a feature by feature rollout. This behavior probably has parts of its reasons in the way a ECMAScript standard is developed. Before any feature is moved to the final stage in the standardization process it has to be implemented in at least two independent implementations, typically browsers. So each feature will probably land in the major browsers eventually, but probably even before the standard they belong to is finalized.
For more information see https://tc39.github.io/process-document/ (see notes at Stage 4, finished).
I implemented CKEditor on a project and I was surprised to discover, either in the interface or in the source code, that it's written in ECMA 6, using all its modern features such as the short function notation (arrow functions).
Given these features are not widely supported as the ECMA 5 version is (not yet as of today, July 2018), I ask why the developers made this strategic choice: are they not interested in a wide browser compatibility? Or is CKEditor so well spread to allow them to dictate a precise direction towards modern browser versions, risking to lose a portion of users?
Browsers are not a problem
Let's be clear here:
CKEditor 5 can be run in all browsers which it supports without any transpilation. All browsers which it supports have a sufficient level of ES6 support.
Why would you need ES5?
The only reason why you might want to transpile CKEditor 5 from ES6 to ES5 are:
Legacy browsers which it doesn't support (at least at the moment).
Existing setups which use ES6-incompatible JS minifiers (UglifyJS). It may be a bit inconvenient to include CKEditor 5 in such applications but, as it was commented already, we explain how to transpile CKEditor 5 to ES5.
Development environments for frameworks like React (create-react-app) or Angular (angular-cli) which didn't catch up yet and still require that libs kept in your node_modules/ are in ES5.
The last case is indeed a bigger problem because you don't have that much control over this environments as on your own projects. As I commented on Twitter:
3 years ago we decided that CKEditor 5 will be released in ES6 because all browsers which we planned to support should have a sufficient ES6 support by our ETA.
We were right – it worked great... in the browsers.
It turned out that the problem is in the build environments (create-react-app, angular-cli) which did not catch up.
We'll need to introduce ES5 builds just to satisfy these envs ;/
To clarify – I'm not criticising authors of these tools. It's more of an observation that we've been always worried about browser support while today the tools stop us.
And, as I mentioned in the other tweet, the problem is broad (e.g. finding a supported, stable, ES6+ compatible and fast minifier – see e.g. https://github.com/webpack-contrib/uglifyjs-webpack-plugin/issues/262 …).
Fortunately, the situation is improving:
#mtrebizan:
I think CRA 2.0 will be shipping non-transpiled code,just don't know how far release is. cc #dan_abramov
#dan_abramov:
There’s alphas you can try. Other than that the ETA is when the community makes it happen 🙂 there’s active work and you can help too
I know there was work in angular-cli on improving this situation too. So, in a relatively short time, all should work smoothly too.
Time aspect
The difference (in terms of features) between ES6 and ES5 is huge. Back in 2014, when we've been starting CKEditor 5 development, we chose ES5. ES6 wasn't standardised yet.
However, the situation changed in 2015. ES6 got published and our tests proved that all features we looked to (classes, generators, iterators, weak sets, weak maps, and more) were already available in Chrome. We decided to go for it and see.
About 1.5 year later CKEditor 5 worked natively (without any transpilation) in all modern browsers (with the exception of Safari which had a nasty bug). At the same time, babel-minify became usable so we didn't have to transpile CKEditor 5 to ES5 even for production.
It's 2018 and the number of obstacles was reduced even more. There's a chance that still this year you won't have to transpile CKEditor 5 to ES5 unless your project is supposed to be ES5 because of browser support (but then, why would you include CKEditor 5? it's not going to work in those browsers anyway).
Looking at the history of CKEditor 3-4, CKEditor 5 will stay with us for the next 8+ years. So, we're talking here about 2026+. This means that for the vast majority of its lifetime ES6 will not be a problem.
CKEditor supports vanilla javascript (ES5) and ES6 as well. The issue is not the editor, it just supports it, doesn't care about compatibility because it doesn't know where your code is going to run but only how to highlight and give you tools to develop it.
The thing is that, by the time, the ECMA standard is under heavy development, improving in every version, so there's a lot going on, there are a lot of proposals being added every month, some passes and makes their way into the standard, which later gets into cool features we can use like arrow function.
All of that makes it harder for browsers to catch on the new updates. Even so, there are a lot that supports the new features now (you may track the updates in that page).
Anyway, besides from all of that, you may use a code compiler like Babel (which compiles ES6/ES7... down to code the browsers can understand such as ES5). It's widely adopted, and recommended for the thing it does: Make your life easier. Many big companies adopted it, such as Facebook which uses react (and made it) using Babel to compile not only ES6 but JSX (check this).
Side note: Why should I use ES6 if I need a compiler?
https://itnext.io/why-you-should-use-es6-56bd12f7ae09
I was looking up the history of JavaScript and found out that the ECMAScript specification is based on it. So JavaScript is older than ECMAScript but seems to have become an implementation of that specification later on.
So what I found out so far is that:
JavaScript 1.0 was the first version
ECMAScript 3 is implemented in JavaScript 1.5
ECMAScript 4 was never completed
ECMAScript 5 is implemented in JavaScript 1.8.5
ECMAScript 6 was released 2015 (therefore it is also called ECMAScript 2015)
ECMAScript 7 was released 2016 (therefore it is also called ECMAScript 2016)
After Version 1.8.5 of JavaScript I can't find any higher version numbers of it. Which versions of JavaScript implement ECMAScript 6 or 7?
According to Wikipedia, the JavaScript-specific version numbers were only used by Firefox, and were dropped in Firefox 4.
These days, there's not really such thing as 'the current version of JavaScript' - the ECMAScript standards get created, and the browser vendors implement the features into their JS engines at their own pace. This pace varies wildly - as demonstrated by the very useful Kangax compatibility table.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript#JavaScript_versions:
Deprecated. The explicit versioning and opt-in of language features was Mozilla-specific and is in process of being removed. Firefox 4 was the last version which referred to an JavaScript version (1.8.5). With new ECMA standards, JavaScript language features are now often mentioned with their initial definition in ECMA-262 Editions such as ECMAScript 2015.
Starting with Firefox 5, changes in JavaScript are listed at https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/Firefox_JavaScript_changelog, but not versioned otherwise.
See the lists at ECMAScript 2015 support in Mozilla and ECMAScript Next support in Mozilla for which features are available in which version of Firefox.
"JavaScript" is a proprietary brand name for an implementation of a scripting language. It was created by Netscape in the early 1990's and, as with all languages, has had revisions over the years. These revisions are tracked with version numbers. Today, JavaScript is maintained by the Mozilla Organization and they continue to evolve the language and track that evolution via version numbers.
However, many years ago, Netscape wanted "JavaScript" to be recognized as the official scripting language of the web and so they approached the "European Computer Manufacturer's Association" (ECMA) to produce a specification that detailed the "official" language. That language (ECMAScript) has also had revisions over the years and those revisions come with version numbers.
Knowing all this, in casual conversation (and sometimes not so casual), people say "JavaScript" when they actually should be saying "ECMAScript". It's like asking for "Kleenex", when you really just mean tissue.
Today, we don't really worry about JavaScript versions any more. We just worry about runtime environments and what they support. It is uncommon for new features to be implemented as a whole. Usually, implementations start bringing in new features of ECMAScript bit-by-bit.
Actually they stopped numbering JS version and only using ECMAScript version and ECMAScript year version (like ES6/ECMAScript2015). Now JS is only standardizd by ES. ES6 and ES7 is implemented on ES5 only.
I wanted to ask a few questions about javascript:
1.Does each browser implement javascript by itself ? Or is their a common SDK\API or whatever ?
2.If each browser implement by itself, Is the javascript engine bounded to the browser version ?
I mean, can I have 2 different engines for the same browser version ?
3.Is there any standards all javascript engines must follow ? Does this standard define memory
allocation ? (Lets say, How I allocate a javascript string ?)
And last,
What are the names of implementation for each browser ? For example I understood FirFox uses an
implementation called "Rhino", Am I right ?
Thanks alot !
Michael
Yes, they implement JavaScript on they're own.
Yes, it is bound to the browser version. No, you can't have 2 different engines for the same browser version. You can though for different browser versions.
Yes, it is called EcmaScript. Most implementation follow it pretty good.
FireFox does not use Rhino. Mozilla developed it, but the implementation in FireFox is different. All browsers implement single-threaded JavaScript, while Rhino is not single-threaded.
Each browser does implement its own version of JS. Thus, why some browsers outperform others. They specification on what JS should do and how it should be done is based on the ECMAScript specification. The only case I've seen of having multiple engines (or versions of engines) is with IE's web dev toolbar, where you can "roll back" your IE version to test how previous versions react. I've found the JS engine to be pretty faithful when doing browser version tests.
Wiki has a nice write up on the different engines. http://en.wikipedia.org/wiki/JavaScript_engine#Mozilla
JavaScript is standardized through the ECMAScript specification which most browsers will adhere to.
However, not all features are implemented across all browsers and browser versions and some features have their own browser specific quirks.
You can find more details about ECMAScript and the versions browsers implement here:-
http://en.wikipedia.org/wiki/ECMAScript
You will not get two different JavaScript engines offered to you within the same browser (usually).