Repository navigation
The state of ES6 on io.js #251
Description
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 --harmony flag.
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
Activity
rvagg commentedon Jan 8, 2015
This is great @ruimarinho and will be a handy reference when we talk about what io.js can do, please keep it updated!
shigeki commentedon Jan 8, 2015
@ruimarinho Great work. https://www.chromestatus.com/features#ES6 is also a good reference to check ES6 features in Chromium V8.
idx3d commentedon Jan 8, 2015
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
Fishrock123 commentedon Jan 8, 2015
This was always the case in node.
bnoordhuis commentedon Jan 8, 2015
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
domenic commentedon Jan 8, 2015
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.
cjihrig commentedon Jan 8, 2015
Any reason not to PR this and have it live on the official io.js wiki?
mreinstein commentedon Jan 8, 2015
@domenic looks like it's
--harmony-classesmikeal commentedon Jan 8, 2015
I'd actually like to get this in to a normal HTML page on the website. I'll port it myself if necessary.
domenic commentedon Jan 8, 2015
I just checked, they moved them under staging. v8/v8@a417b41 Will edit.
snostorm commentedon Jan 8, 2015
@mikeal the same thing crossed my mind (for when io.js has a guides/articles structure.) I opened a ticket (linked in the activity above.)
Fishrock123 commentedon Jan 8, 2015
I'd also like to have this on the website.
at very least, it's worth karma points
ruimarinho commentedon Jan 8, 2015
@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.
domenic commentedon Jan 8, 2015
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.
mreinstein commentedon Jan 8, 2015
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
mikeal commentedon Jan 14, 2015
Sorry, not next version but "version that is shipping around the same time we are targeting to be stable" :)
mreinstein commentedon Jan 14, 2015
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.
mikeal commentedon Jan 14, 2015
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).
mikeal commentedon Jan 14, 2015
I've logged an issue for the next TC meeting about the stabilization cycles and versioning practices. #405
mreinstein commentedon Jan 14, 2015
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.
sounds good to me, thanks @mikeal We've sufficiently beat this issue to death in this ticket. :)
medikoo commentedon Jan 14, 2015
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.
mreinstein commentedon Jan 14, 2015
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.
mikeal commentedon Jan 14, 2015
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.
snostorm commentedon Jan 16, 2015
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.
rvagg commentedon Jan 19, 2015
leaving the tc-agenda label on this but it's really wrapped up in the #405 bundle
Fishrock123 commentedon Jan 22, 2015
See #544 for versioning.
Fishrock123 commentedon Jan 29, 2015
Details of current es6 state can be found on the site: https://iojs.org/es6.html
Discussion will continue in other thread. :)
Migrate from deprecated setter/definer callback signatures (nodejs#251)