6 ms·

ECMAScript 6 compatibility table

74 points by rimunroe 12y ago

frutiger 12y ago
Are module loaders missing in the feature list for ES6?
- kangax 12y ago
  For now, yes. Modules are difficult to test (via regular means like `eval`) and the standard is still in the flux so we're trying to figure out the best way — https://github.com/kangax/compat-table/issues/316 https://github.com/kangax/compat-table/issues/316
  - ahoge 12y ago
    Maybe it would be a good idea to add a note in the meantime. I was quite confused when the module stuff was gone. I assumed it was moved to ES7, but it didn't show up there either. I finally learned the truth after googling a bit and finding that issue. Would have been nice if the page would have told me that right away. Is this the only noteworthy ES6 feature which isn't tested?
    - kangax 12y ago
      Pretty much the only feature, yes. We'll be adding it shortly, sorry for the confusion.
  - frutiger 12y ago
    Would checking for `System.import()` help?
    - Touche 12y ago
      System.import was removed from ES entirely. The Loader spec was moved to WhatWG and is no longer called System.
pornel 12y ago
"Show unstable platforms" + "Sort by number of features" is quite interesting: IE preview wins among browsers. Firefox is close second, and both are ahead of and V8 and even Google's Traceur transpiler.
- magicalist 12y ago
  Number of features isn't a terribly useful comparison, however, since it assumes all features are equal. It's like taking the arithmetic mean of very different benchmarks as a benchmark score. Writing tests for 'let' support, for instance, is harder than just testing that all the Array.prototype methods are now on TypedArrays, so those methods are worth twice that of let support, even though let is considerably more complicated to implement and game changing in its consequences.
  - kangax 12y ago
    Definitely. And that's why we give different weight to different features. Smallest ones (Math methods, octal & binary literals, etc.) have a weight of 0.25. Medium ones (Map, Set, rest parameters, etc.) have a weight of 0.5. Finally, landmark features (arrow functions, classes, generators) have a weight of 1. The final % score is calculated according to all this.
    - Flenser 12y ago
      It would be interesting to see what a combination of Browser + library would support, or to work out which library would increase support over the most browsers.
      - kangax 12y ago
        Yep, it's in the plans! :)
nothrabannosir 12y ago
Typescript seriously needs to start getting its act together. The roadmap shows they're making some headway on these new es6 features, but it feels like they're trying to both accept it for es6 output mode, and for es3/es5 output mode. This means further delays, during which period we can't use them at all. And because typescript != javascript, we can't use any other tools, either. TS is duplicating the 6to5 efforts, with little to show for it. If you use TS, right now you're stuck with es5. It's starting to itch. I wish they'd prioritize the es6 features in es6 output mode and let me worry about converting that to es5.
- aikah 12y ago
  It gets worse when someone tries to use Typescript AND JSX in the same project. A total hell since both languages are incompatible.
  - TheAceOfHearts 12y ago
    Wouldn't it make more sense to go with JSX and Flow?
- antihero 12y ago
  Frankly, I don't see why they don't do something like compiling purely to ES6 and then having the transpiling to ES6 handled by something like Babel.
  - nwah1 12y ago
    Pretty sure that's the plan.
- mixonic 12y ago
  Internally TS is a two pass compilation. First type check, then transpile to ES5. The type check step should be available to run on its own. IMO they should not even worry about transpiling, just be a type checking engine. The API for TS, last I used it, was extremely limited. It has always been viewed as a black box compiler by the authors- they need to expose more flexibility.
benaiah 12y ago
I had no idea how far ahead of node on es6 features io.js was - it passes nearly twice as many of the tests as node (23% vs 40%)
- jared314 12y ago
  > I had no idea how far ahead of node on es6 features io.js was That is because io.js upgraded to a current, and maintained, version of Google V8. This was one of the reasons for the fork. io.js: V8 4.1.x node.js: V8 3.28.x
- tracker1 12y ago
  This comes from being on a current version of V8... Node.js has always been a little behind, and since 0.10 has become very stagnant. Part of the reason for the shift to io.js
deleted 12y ago
[deleted]
izolate 12y ago
That's an aggravating chart for colorblind users.

74 points by rimunroe 12y ago

frutiger 12y ago

Are module loaders missing in the feature list for ES6?

kangax 12y ago
For now, yes. Modules are difficult to test (via regular means like `eval`) and the standard is still in the flux so we're trying to figure out the best way — https://github.com/kangax/compat-table/issues/316 https://github.com/kangax/compat-table/issues/316
- ahoge 12y ago
  Maybe it would be a good idea to add a note in the meantime. I was quite confused when the module stuff was gone. I assumed it was moved to ES7, but it didn't show up there either. I finally learned the truth after googling a bit and finding that issue. Would have been nice if the page would have told me that right away. Is this the only noteworthy ES6 feature which isn't tested?
  - kangax 12y ago
    Pretty much the only feature, yes. We'll be adding it shortly, sorry for the confusion.
- frutiger 12y ago
  Would checking for `System.import()` help?
  - Touche 12y ago
    System.import was removed from ES entirely. The Loader spec was moved to WhatWG and is no longer called System.

pornel 12y ago

"Show unstable platforms" + "Sort by number of features" is quite interesting: IE preview wins among browsers. Firefox is close second, and both are ahead of and V8 and even Google's Traceur transpiler.

magicalist 12y ago
Number of features isn't a terribly useful comparison, however, since it assumes all features are equal. It's like taking the arithmetic mean of very different benchmarks as a benchmark score. Writing tests for 'let' support, for instance, is harder than just testing that all the Array.prototype methods are now on TypedArrays, so those methods are worth twice that of let support, even though let is considerably more complicated to implement and game changing in its consequences.
- kangax 12y ago
  Definitely. And that's why we give different weight to different features. Smallest ones (Math methods, octal & binary literals, etc.) have a weight of 0.25. Medium ones (Map, Set, rest parameters, etc.) have a weight of 0.5. Finally, landmark features (arrow functions, classes, generators) have a weight of 1. The final % score is calculated according to all this.
  - Flenser 12y ago
    It would be interesting to see what a combination of Browser + library would support, or to work out which library would increase support over the most browsers.
    - kangax 12y ago
      Yep, it's in the plans! :)

nothrabannosir 12y ago

Typescript seriously needs to start getting its act together. The roadmap shows they're making some headway on these new es6 features, but it feels like they're trying to both accept it for es6 output mode, and for es3/es5 output mode. This means further delays, during which period we can't use them at all. And because typescript != javascript, we can't use any other tools, either. TS is duplicating the 6to5 efforts, with little to show for it. If you use TS, right now you're stuck with es5. It's starting to itch. I wish they'd prioritize the es6 features in es6 output mode and let me worry about converting that to es5.

aikah 12y ago
It gets worse when someone tries to use Typescript AND JSX in the same project. A total hell since both languages are incompatible.
- TheAceOfHearts 12y ago
  Wouldn't it make more sense to go with JSX and Flow?
antihero 12y ago
Frankly, I don't see why they don't do something like compiling purely to ES6 and then having the transpiling to ES6 handled by something like Babel.
- nwah1 12y ago
  Pretty sure that's the plan.
mixonic 12y ago
Internally TS is a two pass compilation. First type check, then transpile to ES5. The type check step should be available to run on its own. IMO they should not even worry about transpiling, just be a type checking engine. The API for TS, last I used it, was extremely limited. It has always been viewed as a black box compiler by the authors- they need to expose more flexibility.

benaiah 12y ago

I had no idea how far ahead of node on es6 features io.js was - it passes nearly twice as many of the tests as node (23% vs 40%)

jared314 12y ago
> I had no idea how far ahead of node on es6 features io.js was That is because io.js upgraded to a current, and maintained, version of Google V8. This was one of the reasons for the fork. io.js: V8 4.1.x node.js: V8 3.28.x
tracker1 12y ago
This comes from being on a current version of V8... Node.js has always been a little behind, and since 0.10 has become very stagnant. Part of the reason for the shift to io.js

deleted 12y ago

[deleted]

izolate 12y ago

That's an aggravating chart for colorblind users.