Ember and TypeScript

My suspicion is that a promising avenue is to fork the TypeScript compiler so that it emits Ember-type class definitions, so that

export default class extends Ember.Component {
  public foo = "foo";
  constructor() { super(); this.foo = "bar"; }
  @computed('foo') repeated(foo) { return foo.repeat(2); }

would be transpiled into export default Ember.Component.extend({ foo: “foo”, init() { this._super(…arguments); this.set(‘foo’, “bar”); }, @computed(‘foo’) repeated(foo) {return foo.repeat(2); } }

where the @computed decorator does the work of transforming the function into a computed property. With lots and lots of details still to be worked out.

An example of this (transpiling TS into Closure) is at http://bolinfest.com/typescript/.

Glad to see that this age-old thread still is so alive and active! I’m really hoping that something that @rtm envisions eventually materializes. In the best of worlds, we wouldn’t even have to fork the TypeScript compiler but it would be made extensible in terms of what you can do with the output for it.

However, I am also interested in terms of “what can we do right now” with the current (2.1) version of TypeScript and Ember.

This SO thread gave me some ideas; I tried it on a simple hello-world project of mine, but the problem is that I am not exporting a proper Javascript class… i.e. not something based on Ember.Controller.extend. If I in the debugger new this class, I get a seemingly proper instance, i.e. something that has a few __ember properties in it. But, the app doesn’t seem to be able to use this class.

I guess I could perhaps manually Ember.Controller.extend(myClass), but is there a nicer way to get Ember to be able to use this class? Do we already have some form of best-practices on working with Typescript right now apart from this thread?

Some folks are starting to experiment with things over at https://github.com/emberwatch/ember-cli-typescript/blob/master/README.md , might be worth poking your head in there …

Thanks. I have looked there, but it seems extremely early. Doesn’t really give much information about how to write controllers in TS, etc.

FWIW, I discovered Aurelia some days ago and got really excited about it. It’s not exactly Ember.js, but it might still be an interesting option for people starting out new projects and wanting to use TypeScript; it seems like a really pleasant experience. Sorry for the shameless plug, but it still might be an interesting link for people thinking about “what about something like Ember with good support for TypeScript”.

(While we all wait for Ember x.0, rebuilt from the ground up to properly support TypeScript constructs. :stuck_out_tongue: )

@perlun Ember is so mature to easily drop this great framework. There is no cli for aurelia, it’s not integrated with tests and there are so much another missed features. IMO Ember will not be rebuilt from the ground due to great “stability without stanation” policy. As i know, they will eventually make smooth transition to use TypeScript, not big bang like Angular2. And this is great and solid in Ember. The problem is not that it’s not possible to use TypeScript in Ember. I think it’s actually difficult to use TS with EmberCLI, because if you’re using just Ember without CLI, you can easily create for example gulp tasks to compile TS code info ES5 (but it’s really not worth to drop EmberCLI only because of not supporting TypeScript right now). Don’t forget that EcmaScript is also evolving very quickly last years, maybe it will be similar to TypeScript in the future.

Fair enough; that’s a good point and Ember is definitely much more mature than Aurelia. So if maturity is a key element, it’s a better option for sure.

That’s not really true AFAIK, you have the au binary which you can use with au run --watch etc.

Well, the big problem is, as @rtm has been implying, that to “really be able to use TypeScript” you have to change quite a lot of Ember (like Ember.Object.extend to proper OOP inheritance and so forth) which means that it’s not really going to be Ember “as we know it” anymore. Of course you can use TypeScript with ember and ember-cli now already (thanks to the ember-cli-typescript package), but you won’t get the big productivity benefits that static typing provides you with, since you won’t be able to write all your code using classes (because you have to fit it in to Ember’s object model).

Who knows? But not all of us are willing to wait forever. :slight_smile: I think our best bet right now is to hope for Compatibility with ES6 class syntax · Issue #10341 · emberjs/ember.js · GitHub ending up in a proper RFC to “do something” based on decorator syntax/etc.

The entire point of decorators is to provide the kind of meta-programming ability that allows a layer on top of TypeScript that permits us to easily write things like watchable or computable properties, most likely with the use of Proxy. which unfortunately would leave IE11 out in the cold. IMHO the only way forward is to give up on the incremental approach and make a quantum leap of the sort that Angular did, a strategic decision which the Ember designers chose to avoid and criticized. Perhaps some very smart person could write a migration tool that does much of the work of transforming Ember classes into TS classes with Ember-style decorators. If we do not make such a clean break, then sadly Ember will gradually fade into obscurity and become the jQuery of MVC frameworks.

EmberScript? He’s referenced ECMAScript, which is the official JS standard.

The entire point of decorators is to provide the kind of meta-programming ability that allows a layer on top of TypeScript that permits us to easily write things like watchable or computable properties, most likely with the use of Proxy.

All of this is coming to ECMAScript.

IMHO the only way forward is to give up on the incremental approach

There’s really zero need for this. Decorators will come soon, improved TypeScript support for ember apps and addons is being worked on by many folks, and most of ember-core is now written in TypeScript or getting rewritten in TypeScript.

TypeScript itself adopts an incremental approach both in the way it adds typings and in the way it interops with existing JS code.

I don’t understand. Without transitioning the Ember object model to TS classes, how are you going to get type assertions/inferencing/checking on properties, which is the whole point?

I don’t know why Ember should need a complete reset like Angular only for adopting TypeScript. I think the first step is the JavaScript Modules API RFC then we can think about changing the internals of the Ember Object Model and then it should be “easy” to adopt TypeScript. Until all the work is done (and everybody can contribute**), you can still develop your app and upgrade when everything is ready for prime time. I think that’s much nicer than knowing that everything you develop today has to be thrown away because the underlying framework is completely rewritten. But that’s just my point of view.

**) and its better to contribute than to invest time and energy in complaining about things.

I’m deeply confused by your deeply confusing comment. I totally fail to understand why my choice not to spend some meaningful percentage of my personal time working on Ember disqualifies me from expressing my opinion. Is that actually what you are saying, because it sure sounds that way.

The only way for Ember to move into a true TS world is a large-scale conversion effort. If you think that will not involve changing Ember in a way that will require a large migration effort for existing apps, and a large re-learning effort for existing users, or that the JS modules RFC is some kind of meaningful step along the way to doing the TS move, then you are simply revealing your ignorance about both TS and Ember,

That’s a little too much salt if you ask me, but that’s none of my business

It doesn’t disqualify you from expressing your opinion. We live in a free world. Whether we, who work for free in our spare time, can immediately fulfill your request is about resources. If you would help, or pay someone to work on it, it might get done faster. Generally the contributors get the features they want faster, because they make it happen.

I don’t think anyone wants to convert in its entirety, all at once, an existing Ember app into a TS app. What they want to be able to do is have a migration path for those who can, and keep going the old way if they want. And be able to start new apps using the new way. And for bonus points, add some TS classes to an existing Ember app and migrate over time. And for even more bonus points, get some leverage from TS without changing anything. I think that is possible, with the understanding some typing benefits will be lost in those mixed applications. Am I ignorant? Maybe. I don’t claim to be all-knowing.


You are correct, we can do this incrementally fairly easily, and we are. At some point soon, and soon is probably “about a year”, without any changes people will just be able to write some or all of their apps in typescript to their heart’s content.

furthermore, Glimmer is written in TypeScript, and it’s core object (also TypeScript) is very similar to Ember.Object. There’s honestly very little about Ember.Object that keeps us from using TypeScript. TypeScript isn’t a different language.

I’m sorry if you felt offended. This was not my intention. Sure you can express your opinion. And I can express my opinion too. I still think it is possible to pave the road to TypeScript without rewriting everything. But it would be interesting to see examples which show why you think a whole rewrite is needed. The statement “Ember’s object model is not compatible” is a little bit to abstract for me. Maybe you could explain that in more detail and with some code examples.

And I agree with @Gaurav0 that no one will rewrite an entire app at once. So for us it would be ok to stay with js-files for old code and gradually switch them over to TypeScript. Yes we will lose some benefits if we mix JS and TS but I prefer the incremental approach over the “big-bang” approach.

But yeah, maybe I don’t see the real problems. Would be great if @rtm could explain them to me. Probably this is possible with some pseudo-code samples.

Check this section, it sorta gives you an idea of why it’s not compatible

Yes I see, but I don’t know why you couldn’t wrap all this functionality into TypeScript classes and then just use or extend these classes. Then of course you wouldn’t replace the Ember-Objects with “pure” TypeScript classes but I’m not sure if this is necessary.