https://medium.com/dailyjs/we-jumped-the-gun-moving-react-components-to-es2015-class-syntax-2b2bb6f35cb3 … 1: As much as it hurt, I'm happy Ember hung back on ES2015 class syntax.
-
-
4: Now that there's a clear path to a good developer experience, we're starting to plan the transition:https://github.com/emberjs/rfcs/pull/240 …
-
5: But as an Ember developer myself, I have appreciated the stability of a working, featureful object model while ES2015 classes fleshed out
-
6: Not everyone remembers, but ES2015 intentionally shipped what we called "max-min" classes. We got consensus for what everyone knew
-
7: was a too-limited feature set as an incremental step that we could build on in future versions. It saddened me at the time, but I knew
-
8: Ember wouldn't be able to use ES2015 classes as-is. I gave my agreement for them and immediately got to work on the next steps.
-
9/9: I'm enthusiastic about what we can build on top of a fleshed out class model, and happy (but exhausted) for having held out until now.
-
I don't understand. class fields and decorators have been supported by Babel for ages - why can't Ember devs use them just like React devs?
-
1: Nothing is stopping Ember devs. https://github.com/ember-decorators/ember-decorators …
@rwjblue is on the core team. The core project is just more conservative - 14 more replies
New conversation -
-
-
Personal unpopular opinion: I think decorators should've just been annotations. But only because the latter is statically analyzable.
-
I think decorators are cool. I just worry we're giving up optimizations we could have otherwise had. But what do I know? /shrug
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.