The state of ES6 on io.js

[ruimarinho]

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

[rvagg]

This is great @ruimarinho and will be a handy reference when we talk about what io.js can do, please keep it updated!

[shigeki]

@ruimarinho Great work. https://www.chromestatus.com/features#ES6 is also a good reference to check ES6 features in Chromium V8.

[idx3d]

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]

I didn't know that shipping (stable) features will be enabled by default.

This was always the case in node.

[bnoordhuis]

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]

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]

Any reason not to PR this and have it live on the official io.js wiki?

[mreinstein]

@domenic looks like it's --harmony-classes

[mikeal]

I'd actually like to get this in to a normal HTML page on the website. I'll port it myself if necessary.

[domenic]

I just checked, they moved them under staging. v8/v8@a417b41 Will edit.

[snostorm]

@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]

I'd also like to have this on the website.

at very least, it's worth karma points

[ruimarinho]

@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-classes as @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]

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]

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.

[ruimarinho]

@domenic, @mreinstein, thanks for the insight. In that case, I see two options - downgrading back to 3.30, which I think would remove way too many ES6 goodies, or ship io.js 1.0.0 with the next 3.32.x release which will not ship classes by default. @bnoordhuis?

[rvagg]

The removal of classes in the next V8 will make it a breaking change and will bring us straight to a 2.0.0 release (which, perhaps, is fine). We could consider manually removing classes or only merging in the changes from 3.32 that disable them and put them behind a flag?

[Fishrock123]

Please see https://groups.google.com/forum/#!topic/v8-users/RkobpinkoKM

[rvagg]

@domenic in light of the feedback you got on v8-users (above) about versioning, what's your recommendation to io.js about V8 versions? should we take that advice straight and stick with stable chrome versions? keeping in mind that there's not a whole lot of desire for conservatism in this project.

The TC should also get involved in this discussion (see above link), specifically in relation to 1.0.0 / @bnoordhuis @piscisaureus @isaacs @indutny @trevnorris @chrisdickinson @cjihrig

[mreinstein]

keeping in mind that there's not a whole lot of desire for conservatism in this project.

conservatism is relative. I think even if we where to just stick with the newest chrome's stable release channel, we would be radical (at least compared to node.)

[domenic]

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.

For the 1.0 alpha though, I'd suggest skipping ahead to 3.30 as described since Chrome M40 is going to drop very soon now.

[rvagg]

@bnoordhuis that would mean reverting the 3.31 merge, thoughts on that?

[piscisaureus]

(side note: @rvagg there is a shortcut for that: @iojs/tc)

[cjihrig]

Is there a drawback to shipping what stable Chrome uses? Seems like the safest bet, and as previously pointed out, it would still move at light speed compared to joyent/node.

[bnoordhuis]

@rvagg If the question is whether I'm worried about bugs in 3.31, the answer is 'no'; V8 has a pretty exhaustive test harness (that, importantly, passes - as does ours.) The issue is not one of bugs but of spec conformance.

I would suggest disabling classes for now and enable them again when we upgrade to 3.32 or 3.33. I'll prepare a PR.

[rvagg]

@bnoordhuis no, I'm not worried about bugs, what worries me here is the introduction of breaking changes from V8, I'd personally like to see V8 have feature introductions more than breaking changes--we'll probably get enough breaking changes from the C++ API. I'm imagining the situation where we have to bump to 2.0.0 not longer after our 1.0.0. We probably shouldn't be afraid of semver but we should have some concern for the perception of the stability of our process that our version numbers are going to create.

So yes, disabling classes is a fine solution this time, but perhaps we ought be a bit more cautious in pulling V8 versions and stick closer to the stable Chrome version?

[bnoordhuis]

I'm somewhere in the middle. I don't disagree with caution but the particular example of classes was because of last minute changes to the ES6 spec (you can find the mailing list discussion here.) Let's discuss a policy at the next TC meeting.

[mikeal]

I've logged an issue for the next TC meeting about the stabilization cycles and versioning practices. #405

[mreinstein]

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. :)

[medikoo]

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.

[mreinstein]

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]

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]

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.

[rvagg]

leaving the tc-agenda label on this but it's really wrapped up in the #405 bundle

[Fishrock123]

See #544 for versioning.

[Fishrock123]

Details of current es6 state can be found on the site: https://iojs.org/es6.html

Discussion will continue in other thread. :)