@canufeel this seems to be an interesting approach. Great to hear there are people pushing the integrating of TypeScript and Ember. Maybe you could get more traction if you distribute your link in the Ember Slack Community, since the Slack Community is very active and this thread is very old in contrast.
Nevertheless, I already gave +1 on github 
While this is less about using type script specifically and more about adding typing to a project using ember, one particularly extreme approach to this problem could be to build a custom typing tool that recognises the semantics of the Ember object model with the get and set methods, etc.
Again an extreme approach, but hey It’s a free idea if anyone is willing to go and implement it
@akst yes this could be also an option. But I’m not sure if it is a good idea to do something that “extreme”, especially without support of the core team. Because if there are aspirations to change the object model, you would have to reimplement everything. Yeah I don’t know 
but I would love to see traction on Ember and Typescript.
Why in the world would I develop my own typing tool given the huge amount of work that has already been done by TypeScript and Flow. Also, this would not only be a “tool”; it would also need to involve new syntax, essentially meaning that you would be forking the JavaScript language itself.
But I’m not able to figure out how to create the actions has
The problem is that actions and the way they are sort-of-members-but-not-really, and “inherit” from superclasses and/or mixins, is poorly conceived and designed, and breaks standard inheritance paradigms.
I know people are thinking about how to move Ember into the ES6/typed world, but I’d be surprised if anything happened too quickly. The main problem is that it’s HARD. In fact, it may be impossible to do this and end up with anything resembling Ember as we know it. There is quite a large impedance mismatch. The Ember team has boxed itself in by very publicly committing to an incremental, phased innovation strategy. The problem is that you cannot move from horse and buggy to automobile in incremental, phased fashion.
Let me go out on a limb here and say that the entire “convention over configuration” mantra is now turning out to be a millstone around Ember’s neck. The thing is, as it turns out, conventions can be prison cells you lock yourself into, and they make assumptions which do not necessarily hold true as technology changes rapidly. I have no illusions that I can change the minds of people whose entire professional careers have been devoted to this ideology, but I certainly side with the “Tools, not Rules” people in this case.
Personally I don’t think we need to move to TypeScript with the get/set pattern intact. It’s time to move on. Even with the recent TS2.1 enhancements, there are uncheckable constructs, and there may not have been alternatives six years ago if one wanted watchable properties, but today there are different approaches.
I was coming from the other side (which means basically configuration over convention). I work with Ember now for 2 years and I enjoy it more and more every day. In contrast to other mantras we were able to continuously upgrade Ember. We started with Ember 1.6.1 and Ember-CLI 0.0.40 now we are on the latest stable version of Ember, Ember-Data and Ember-CLI. Since our first days with Ember a lot of things happened. We as Ember Community got new render engines, we got Ember Fastboot, we got Ember Engines, we got a healthy plugin and addon ecosystem and many more things. And as application developers we can leverage these progressions without huge upgrade pains. Angular was completely rewritten and because there were no convetions enforced by the community, upgrading is almost impossible and everybody faces different challenges. Or React, show me one project which is 2 years old and is still up-to-date. And now back to topic
Yes maybe some features can not be implemented as fast as if there are no conventions (and you don’t need to care about backwards compatibility) but in the long run, many (or almost all) of the great advancements of web technologics will come to Ember.
And yes, I would love to see some static typing in Ember and I think TypeScript is a good candidate for that. I don’t think static typing is the biggest problem right now and so I’m fine if we still have to wait for the adoption of static typing in the Ember Community. I think things like the JavaScript Module RFC are going into the right direction and could pave the way to static typing.
From my point of view, the first thing to do to get static typing is to define which problems we want to solve with static typing and then how we (as a community) could solve these issues. If the community agrees on an approach, I think static typing could be implemented quickly and made accessible to all users of Ember. And this would be due to the “convention over configuration” mantra. Also adoption would be easy because everybody has the same setup and if there arise problems the community can help.
Remember this the next time you spend five minutes tracking down a this.set('mispelledProperty') bug, which TypeScript would have found in five seconds.
The problem we want to solve with static typing is, uhh, we want to have static typing. I think you would be flabbergasted by the improvements in development productivity–a factor of two is a very conservative estimate.
I know the benefits of static typing (I also worked a lot with C/C++ and Java) and I agree with you, that it can help productivity.
Another aspect of static typing are compile(transpile)-time-optimizations. You could optimize/minimize the code much more aggressive if you know the access modifier etc.
Furthermore static code analyze tools could catch possible errors early. Code linting could advance to the next level etc etc.
So there are many topics which can benefit from static typing.
And your example with this.set is a good one. I also think that it is annoying if you mistype the property name. But there is the question on how you want to solve this problem with static typing. Do you want to get rid of the set method completely or do you want to type the set method somehow.
Yes I believe in the power of static typing but I think it is too easy to just say “Ember needs static typing because static typing is awesome”. Without a detailed attack plan, it will not be possible to implement static typing into Ember. And this is what I meant when I said, we need to agree about the main problems and how to solve them with static typing.
Move beyond get and set. Yes, I know it’s a huge change, which is why I said the result might no longer be recognizable as Ember.
Conventions can change in time. no need to lock them. We shall use our passion not to argue with each other, but to come up with approaches
Totally agree 
I would be in for adding statically typing to Ember but right now I don’t know where to start and how we should approach this topic. If someone else is also motivated, we could team up
Awesome news! keyOf and lookup types in TypeScript 2.1 are perfect for Ember!
Interesting how this.get(‘foo.nested.bar’) will work
This is going to get you about 10% of the way towards working in Ember with TypeScript, no further. This works only with objects which TS understands the shape of; Ember objects are not TypeScript objects. It also provides no help with tooling, which is arguably one of the most important features of TypeScript; for instance, my IDE can show me the place a member property is defined, or show me all the places a member property is referenced. As another comment correctly points out, it also does not help with constructs such as this.get('foo.bar').
IMHO it was slightly irresponsible for the TS authors to claim that this is “serving users of libraries like Ember”, without apparently understanding any of the Ember issues.
I don’t know a whole lot about TypeScript, but seen Tom Dale tweet this recently.
I’m not sure how I would want the perfect combination of TypeScript and Ember to be. I’m not sure if just typing the get/set pattern is “enough”. If you get rid of the get/set completally you would have to define all the properties beforehand to add getter/setter.
Yeah I like static typing, I like TypeScript and I also like Ember but the more I think about it the more I doubt that these two technologies can work together soon.
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.