Ember.js: Compatibility with ES6 class syntax

[fivetanley]

This would be a great feature and usable by people using 6to5 in ember-cli. What kind of work would need to go in to make this possible?

• [x] align _super and super
• [ ] es2016 decorators stability
• [x] loose mode proto for IE8 (for now) we don't support IE8 in 2.0
• [x] constructor vs init vs ..
  i suspect constructor will be the new form, with the new behaviour i would prefer, and init will fire after?...

[topaxi]

Kind of related https://github.com/rwjblue/ember-cli-esnext/issues/7

[stefanpenner]

Won't be possible until js adds annotations. Also won't work in ie8.

That being said, I am sure we all want this.

[donaldpipowitch]

It looks like Angular and TypeScript teams working together with @wycats to get a proper annotations specification (see http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx). I hope this can be transpiled with Babel easily to get real ES6 class support.

[wycats]

The annotations proposal and a proposal for declarative properties are going to be brought to TC39 at the Paris meeting on March 24.

I anticipate support in Babel pretty quickly assuming all goes well. :smile:

[stefanpenner]

@wycats we will also need jshint support, for annotations, can you apply pressure?

[wycats]

@stefanpenner once we have an advanced proposal, I'll try and get it done.

[stefanpenner]

@stefanpenner once we have an advanced proposal, I'll try and get it done.

:+1: if we can get those tooling pieces tee'd up, we can roll this out much quicker.

@wycats we need to figure out this._super and super interop still.

[wycats]

@stefanpenner yeah. There's an ES7 super proposal coming up in Paris as well. I'll make sure to keep the Ember use case in mind.

[stefanpenner]

@stefanpenner yeah. There's an ES7 super proposal coming up in Paris as well. I'll make sure to keep the Ember use case in mind.

thanks, keep me in the loop. I'll gladly prototype something if i have the proposal.

[donaldpipowitch]

I'm not sure if this discussion overlaps, but the React team looks into how mixins could be expressed for ES6 classes (https://github.com/facebook/react/issues/1380). It looks like this could be done solved with an annotation on a class, too...? Just to point to another use case outside of Ember.

[stefanpenner]

@donaldpipowitch awesome, good resource, will read it shortly.

I believe, as the thing to the right of extends is just an expression, and that super desugars to toMethod we may be in the clear.

[thehydroimpulse]

/cc me

[trek]

@thehydroimpulse for future reference you can use the Notifications button on any issue to get notifications without sending everyone a message :raised_hands:

[thehydroimpulse]

@trek Unfortunately, if you're watching a project, you're technically already subscribed to all issues, but you don't get email notifications. Commenting is unfortunately the only way around it.

[lolmaus]

@thehydroimpulse, go here https://github.com/settings/notifications and enable email notifications for watched repos.

[Globegitter]

Seems like Aurelia is making use of some of the features @wycats mentioned. They are using decorators for dependency injection. Also now that IE8 support is being dropped seems like there could be some movement happening in that direction.

[stefanpenner]

Also now that IE8 support is being dropped seems like there could be some movement happening in that direction.

Yes this is/was the largest barrier. The next largest is actually the copious amount of re-factoring, and the incompatibility between ES5 and ES6 classes (specifically the lack of desugaring for super).

[kottenator]

It would be great to use ES6 super-powered methods instead of magical this._super(...)
I guess it's not possible until Ember will switch to ES6 classes (for all the base classes).
As for IE8 support - as I understand, Ember 2.0 will drop it, so it's not a problem.

[rwjblue]

Much work has been done on this, there is a pending PR by @stefenpenner that makes the required changes (still needs a few changes/fixed IIRC).

[stefanpenner]

I guess it's not possible until Ember will switch to ES6 classes (for all the base classes).

For classes super works correctly, our superWrappering makes it "just work" today. Mostly we are just waiting on 3 things:

1. decorator spec to be finalized – we can't start relying on on-finalized spec :(
2. IE8 to be dropped
3. extraction of the mixin helper

Without 1 + 2, 3 serves very little value in core. Although it may be provided as an add-on.

[stefanpenner]

i have updated the above checkboxes (and edited some of the words)

loose mode proto for IE8 (for now)

@fivetanley im not sure what this means, but I suspect this doesn't matter as ember 2.0 drops IE8?

[knownasilya]

Can't wait!!! Has there been any work on this since the last update?

[rosshadden]

Is the decorators spec stable enough to do this now? rwjblue's project is a great step in the right direction, but having classes and decorators built-in to Ember would dramatically improve developer experiences (not to mention morale :-D).

[listepo]

:+1:

[chadhietala]

@rosshadden Still at Stage 1, but many improvements have been made to the spec. https://github.com/wycats/javascript-decorators/pull/36

[stefanpenner]

@rosshadden yes we agree, and this is why @wycats and myself are on tc39. To push aspects of the spec that benefit our day to day forward.

In-fact the decorator spec is largely championed by @wycats

[pixelhandler]

Going foward should this "feature" issue be tracked in the emberjs/rfcs repo?

[locks]

^ agreed

[rosshadden]

Please link us to whatever the spiritual successor of this issue ends up being once it is created, so those of us that are interested may subscribe to it.

Thanks.

[mixonic]

@rosshadden watching the https://github.com/emberjs/rfcs repo is the best bet for you to stay up to date on how this happens. I highly doubt whoever takes the next steps would remember to update this ticket directly, even if they knew it exists (the next person to move on it might be someone we don't know today)!

[lolmaus]

Why have we closed this before an RFC was created?

Normally such action means a rejection.

[mmun]

This issue tracker is for bugs only. Features go in the RFCs repository. For more details read https://github.com/emberjs/ember.js/blob/master/CONTRIBUTING.md#requesting-a-feature.

[stefanpenner]

Normally such action means a rejection.

not here

[stefanpenner]

basically, the primary barrier is:

EcmaScript decorators stability

We are working on it from TC39 side of things.

[wycats]

Why have we closed this before an RFC was created?
Normally such action means a rejection.

I understand why you might have felt that way, and we probably should have been clearer: moving to standard JavaScript classes is a top-priority for us. It requires careful design and interoperability work, and as Stef said, any plausible transition will require JavaScript decorators.

I am working on decorators at TC39 and hope to advance them far enough in the next meeting (in Munich) that we can start seriously starting to plan a transition.

[wycats]

I unlocked the conversation, but would suggest that any further discussion to lay the groundwork for this feature should happen in an issue on the RFC repository, and should probably either present or wait for a straw-man that uses JavaScript decorators.

[chadhietala]

Just a reminder we could very well be be doing static analysis and compiling to what decorators would compile to in Babel or TypeScript. While there are ergonomic things at steak from the consumer point of view, there are some performance benefits of doing this as well.

[stefanpenner]

@chadhietala ya, if done right we can avoid the applyMixins costs we do today.

[karellm]

Is there any update on this? Thanks!

[locks]

@karellm not yet, still work to do and decorators are only stage 2!

[knownasilya]

stage 2 means ember needs to be on it.. 😄

[tatyahoo]

It looks like ES6 classes for Ember are already supported using ember-cli-babel...Is there some other "official" way to do it or is that still on hold?

[knownasilya]

@tatyahoo babel allows classes, but Ember has Ember.Object which is used throughout the framework for things like observing properties, unknown properties, etc., so moving to classes isn't so simple.

[tatyahoo]

@knownasilya So does that mean that even though the below code works, it's not functioning the same as the normal way and unsafe?

import Ember from 'ember';

const {
  Component
} = Ember;

export default class extends Component {
  
}