Repository navigation
The state of ES6 on io.js #251
Description
Activity
This is great @ruimarinho and will be a handy reference when we talk about what io.js can do, please keep it updated!
@ruimarinho Great work. https://www.chromestatus.com/features#ES6 is also a good reference to check ES6 features in Chromium V8.
Thats is great! I didn't know that shipping (stable) features will be enabled by default. For me it is one of most important pros of io.js
I didn't know that shipping (stable) features will be enabled by default.
This was always the case in node.
Apropos ES6 classes, V8 has stated their intent to unship them again for the time being: https://groups.google.com/d/msg/v8-users/To0IehKbwH8/CA9fWRsy7nEJ
I updated a variety of things on that page for accuracy, both from a TC39 perspective and a V8 perspective. I didn't make the classes update yet since I haven't yet checked what flag they moved under.
Any reason not to PR this and have it live on the official io.js wiki?
@domenic looks like it's
--harmony-classesI'd actually like to get this in to a normal HTML page on the website. I'll port it myself if necessary.
I just checked, they moved them under staging. v8/v8@a417b41 Will edit.
I'd also like to have this on the website.
at very least, it's worth karma points
@rvagg: thanks, I'll be adding the link and a quick overview of the relation between Chromium/V8/io.js.
@bnoordhuis: thanks for the enlightening thread link! From my perspective, what is being discussed by Dmitry (subclassing exotic objects and DOM objects) does not apply to io.js, so we should discuss whether it is acceptable to ship io.js with V8 3.31.74, where classes are indeed shipping by default. It is also very comfortable to know that it should only take around 6 weeks to move classes back to shipping again, which means io.js developers can start playing around with this feature now.
@cjihrig: there isn't a way to submit a PR to a wiki on github, which is a shame, so until I have feedback from TC whether it is appropriate to edit the io.js' wiki directly or if there is another mean of posting this information available under the io.js organization for discussion, I'd like to keep it separately for proper review of TC, collaborators and community in general.
@domenic: thank you for the updates. Indeed, the flag is
--harmony-classesas @mreinstein mentioned, but it also implies object literal extensions moving to the staged area 😢@mikeal: happy to do it. I'd like to discuss beforehand how we should organize guides and articles. Thanks @snostorm for starting this discussion!
Thanks for all the feedback and corrections so far.
You should not ship classes. The semantics of constructors have changed in ways that will make the code you write incompatible with the spec-compliant V8 (not just when subclassing DOM objects). Besides, subclassing Array does definitely apply in io.js.
The Jan 7th TC39 meeting resulted in well-agreed-upon changes [1]. In addition to that, it doesn't sound like this will delay the release of es6 classes that conform to this new syntax by long (current estimates are one release cycle, 6 weeks.) [2]
[1] https://github.com/tc39/ecma262/blob/master/workingdocs/ES6-super-construct%3Dproposal.md
[2] https://groups.google.com/d/msg/v8-users/To0IehKbwH8/CA9fWRsy7nEJ
It seems like the best thing to do (for now) is to let the classes implementation stabilize in v8.
48 remaining items
Sorry, not next version but "version that is shipping around the same time we are targeting to be stable" :)
Remember, we are currently "unstable" and plan to stabilize around the same time
the v8 team expect to ship their next version in Chrome so this should still all line up nicely.I get that, and I appreciate the forward looking attitude. It's a breath of fresh air compared to the stagnant situation happening with node/joyent.
The problem is, we've put the first release out there, and we based the version on what we expected to happen with the v8 releases, and the very first one is already based on assumptions that changed out from under us. We also pushed out a 1.0.x release that is an alpha. While it's not a huge problem it's already not adhering to semver.
I'm not saying it's the end of the world but it doesn't seem like a great way to start the ball rolling. I hope in the future we can setup more formal release channels so this doesnt happen, and tack onto v8's reliable release schedule.
We also pushed out a 1.0.x release that is an alpha.
According to semver the increments correspond to changes in API compatibility and not the stability of release. In other words, 1.0.0 is not necessarily stable and 1.0.1 is assured to be API compatible with 1.0.0 (which was true).
the increments correspond to changes in API compatibility and not the stability of release.
True, it just seems odd to that we'd try to take a different project (nodejs) and align with it's versioning scheme. Technically iojs has no api compatibility because it's never released. I assume what matters is npm compatibility and version numbers wont be sufficient to detect that.
I've logged an issue for the next TC meeting
sounds good to me, thanks @mikeal We've sufficiently beat this issue to death in this ticket. :)
According to semver the increments correspond to changes in API compatibility and not the stability of release.
That's a surprising interpretation, to my understanding semver always proposed something else, and v1 was about production ready and stable product. Excerpt from semver.org:
How do I know when to release 1.0.0?
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
The key word in there is "probably". It's not strictly violating semver to have an alpha release as 1.0.0 but that does seem to be the common convention, which is what threw me off as well.
I also don't agree with cutting a 1.0.0 on the premise that it somehow makes more clear that iojs is a continuation of node's work. I think anyone that finds iojs or knows why it was created doesn't need help inferring things from a version number.
It's already a done thing though. We should look to #405 as an opportunity to address this issue with future releases. Dwelling on the past isn't super productive.
The 1.0.0 version also speaks the relative maturity of the project. I'm comfortable saying that more bits are moving through Node in production right now than Python or Ruby so calling it anything below 1.0 is misleading.
I would say stay with the stable Chrome version. If you'd want you could investigate releasing e.g. iojs 1.x+v8beta, 1.x+v8dev, 1.x+v8canary in the future.
I've been meaning to +1 this general idea. Nightlies play an important role but I think if we're following a predictable (6 week?) "release" cycle based on releasing larger changes (versus ongoing minor patches) and V8 updates, it would help to empower users to start provide feedback on those upcoming changes weeks ahead of time.
See #544 for versioning.
Details of current es6 state can be found on the site: https://iojs.org/es6.html
Discussion will continue in other thread. :)
- added a commit that references this issue
on May 11, 2026
ES6 feature availability on io.js can have a significant impact on the node developer community. There is an ever increasing demand for ES6-compatible/ready tools and node was on the prehistory regarding ES6. While transpilers have had their fair share on frontend tools, their usage on node is fairly limited due to an unbalanced gain between their added complexity versus the
--harmonyflag.While v8 is not particularly known for their efforts on ES6 implementation on the past, that has changed dramatically in the most recent versions, and 3.31.x is a solid proof of that. I'm really glad the TC decided to ship this version of v8 on 1.0.0.
As @rvagg puts it, ES6 can be a "trademark" for io.js. Because of this, I've written a new page dedicated to this topic on a "forked" wiki for discussion. There are probably many things left to add and clarify, but this was the best place I found to start this discussion. If you'd like me to submit a PR in another form, please let me know.
https://github.com/seegno/io.js/wiki/The-state-of-ES6-on-io.js