Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The state of ES6 on io.js #251

Closed
ruimarinho opened this issue Jan 8, 2015 · 70 comments
Closed

The state of ES6 on io.js #251

ruimarinho opened this issue Jan 8, 2015 · 70 comments

Comments

@ruimarinho
Copy link

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
Copy link
Member

rvagg commented 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
Copy link
Contributor

shigeki commented 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
Copy link

idx3d commented 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
Copy link
Contributor

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

This was always the case in node.

@bnoordhuis
Copy link
Member

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
Copy link
Contributor

domenic commented 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
Copy link
Contributor

cjihrig commented Jan 8, 2015

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

@mreinstein
Copy link

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

@mikeal
Copy link
Contributor

mikeal commented 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
Copy link
Contributor

domenic commented Jan 8, 2015

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

@snostorm
Copy link

snostorm commented 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
Copy link
Contributor

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

at very least, it's worth karma points

@ruimarinho
Copy link
Author

@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
Copy link
Contributor

domenic commented 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
Copy link

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
Copy link
Author

@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
Copy link
Member

rvagg commented Jan 8, 2015

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
Copy link
Contributor

@rvagg
Copy link
Member

rvagg commented Jan 9, 2015

@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
Copy link

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
Copy link
Contributor

domenic commented Jan 9, 2015

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
Copy link
Member

rvagg commented Jan 9, 2015

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

@piscisaureus
Copy link
Contributor

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

@cjihrig
Copy link
Contributor

cjihrig commented Jan 9, 2015

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
Copy link
Member

@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
Copy link
Member

rvagg commented Jan 9, 2015

@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
Copy link
Member

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
Copy link
Contributor

mikeal commented Jan 14, 2015

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

@mreinstein
Copy link

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
Copy link

medikoo commented Jan 14, 2015

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
Copy link

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
Copy link
Contributor

mikeal commented 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
Copy link

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
Copy link
Member

rvagg commented Jan 19, 2015

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

@Fishrock123
Copy link
Contributor

See #544 for versioning.

@Fishrock123
Copy link
Contributor

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

Discussion will continue in other thread. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests