Ember and TypeScript

Slippery slope–if conventions change too much, they are no longer conventions. The whole point of conventions is that they are dependably stable. Would you change the Geneva Conventions?

It’s a reasonable guess that a TypeScript version of Ember will use decorators in some fashion to set up the necessary getters and setters on properties, as well as define computed properties, etc.

I, for one, would love to be using TypeScript and Ember projects today. Can’t do it because of Ember’s object model. Don’t see it happening anytime soon either, but won’t give up hope. Love that wcats is trying to get some stuff out of the way syncing with the TypeScript/Microsoft people.

@tsantos83 since the first step to get something going is, to write a RFC, I think we should discuss how a mix of Ember/Typescript would look in the perfect world. How would you like to use Typescript in Ember?

Like @rtm described I think decorators would be an option. I also think we should get rid of the get/set at all if we switch to Typescript. The disadvantage would be of course that we have to define all properties upfront.

@krautman I would love to help but I don’t think I know what’s involved for this type of commitment; so, some guidance would be required.

As for using TS with Ember, I would like to use typed collections (generic-like collections) similarly to how generics work in .NET or Java. Also the static-typing and interfaces are really helpful for me in general. As for the anonymous class members, I would think that it can be resolved with interfaces too, but in a more complex way. Transpiled TS (in my experience) tend to have a better performance than transpiled JS (but I have nothing that I can show you right now that supports my claim, just an observation over time), even better if you can deploy to somewhere that has ts-node.

I’m down with changing conventions within reason when/if necessary, and also down with the use of decorators (we use it in koa already, so), but yeah, getting rid of get/set would be nice but it should probably be like sequelize, as they have get/set even in v4, but dot notation also works, so it doesn’t break old stuff and newer stuff gets to call a nicer api.

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 https://github.com/emberjs/ember.js/issues/10341 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.