RFC: Official TypeScript support #724
Conversation
TypeScript has become a key part of the front-end development ecosystem over the past several years, and powers many of the best developer experiences in the front-end ecosystem. Ember was a relatively early TypeScript adopter for its internals, and there is widespread usage in the ecosystem with community support, but to date Ember has not provided “out of the box” or official support for authoring apps or addons in TypeScript. This RFC declares our intent to make TypeScript a first-class citizen of the Ember ecosystem, as a peer to JavaScript, in a way which makes the developer experience better for *all* Ember developers. It outlines the key constraints and goals for the effort, details a roadmap for accomplishing those goals, and provides the following definition of official support (from the Detailed Design: Defining Official Support section in the RFC text): > Ember officially supporting TypeScript means: _**All libraries which > are installed as part of the default blueprint must ship accurate and > up-to-date type definitions for the current edition. These types will > uphold a Semantic Versioning commitment which includes a definition of > SemVer for TypeScript types as well as a specification of supported > compiler versions and settings, so that TypeScript will receive the > same stability commitments as the rest of Ember.**_
chriskrycho
force-pushed
the
intent-to-ts
branch
from
1cf6ab7
to
dc7136c
Compare
|
@chriskrycho - Thanks for working on this! I'm definitely excited to move forward here! |
rwjblue
added
T-infrastructure
T-Tooling
|
@chriskrycho I'm a huge +1 on this RFC, generally speaking. It's been a challenge authoring Ember addons using third-party types à la DefinitelyTyped. While I'm thankful that those that contributed to DefinitelyTyped did, it's a challenge using types derived through third-party interpretation vs. first-party types. Thanks for doing this! |
|
Based on what I read, it sounds like this will more or less allow developers to use TypeScript out of the box without having to install However, if we intend to move TypeScript as a "first-class citizen", then I think we should consider the cons listed in this RFC:
If ember decided to adopt TypeScript as a "first-class citizen", that would endanger the library from falling into the same pitfall Angular 2 (and over) did. A lot of developers got scared away and abandoned the framework due to the radical changes imposed. That doesn't mean that Ember can't do it, but I think we should tread carefully in this endevour. Angular 2 introduced what, in the Ember world, we know as Ember Engines (Angular Modules). With the adoption of TypeScript came the concept of Definitely TypedTypeScript presents the main benefit of allowing developers to see method parameters and requirements in real-time via VS Code. While this does provide a benefit to the writier, we can also get the same affordance with older tools like Therefore, I think it makes more sense to just use JSDoc before jumping for more tooling and imposing a learning requirement on developers. A quick Google search reveals that TypeScript has more problems than we may have thought. Of course, we can easily find reasons to or not to use a certain technology, but I argue that with the trend of tooling becoming less favourable, it makes more sense to opt for less tooling over more. |
|
@srsgores thanks for your comment. I think it’s a great chance to be extra clear about what this RFC does and does not propose.
If we were following the path Angular took, where TypeScript became the only supported language and JavaScript was demoted to a second-class language (at best), I would share your hesitation on this point. But we are not following that path! Our goal is to make TypeScript as equally-well-supported as JavaScript, not to push JavaScript aside. As such, the RFC expressly outlines a number of key differences between what we're proposing and what Angular did. As described under Constraints:
And, from Non-Goals: Superseding or replacing JavaScript:
These constraints represent critical differences from the path Angular took. (They are in fact directly informed by watching Angular's problems!) Angular violated all of those principles. We take them as hard and fast guidelines on our adoption.
This is a mostly-accurate summary of the direct benefits for JavaScript-only developers. However, for authors working in TypeScript, the feedback provided by supplying up-to-date, accurate, and well-tested types is much stronger: it can actually prevent whole classes of bugs. Moreover, while JSDoc annotations can provide a similar degree of benefit purely on the autocomplete and documentation side if the JSDoc annotations are published in modules, that approach would have a number of significant downsides vs. publishing TypeScript types:
Additionally, it’s worth noting that in most modern editors, the JSDoc-powered feedback is actually still TypeScript-powered feedback! It’s just a weaker and worse version of what can be provided by type definitions.
If you mean “imposing a learning requirement on developers of Ember itself” that learning requirement already exists: much of Ember is written in TypeScript already. If you mean “imposing a learning requirement on developers of Ember apps and addons,” then nothing about this proposal would do any such thing. It would particularly benefit TypeScript developers, but it would not impose anything on JS-only developers; indeed, it would only make things better for them (with no effort on their part!). Again: this is an explicit constraint of the effort, and we won't compromise on that commitment! To address your other points:
This is indeed a concern that we’ll need to think about carefully in how we approach the documentation design! We do not want to overwhelm people as they are just getting started. Particularly for the design of the Guides, we’ll need to figure out the best way to structure them. On the other hand, TypeScript may actually help with API docs, even for JavaScript-only consumers.
While this is true in a strict sense, there are a few reasons I don’t think it’s relevant to our decision of whether to support TypeScript officially as a framework:
A quick Google search will also reveal that some people don’t even like delicious chocolate ice cream. 😱 🍨 There is, as far as I can tell, no trend of “tooling becoming less favourable” as far as TypeScript goes. I have looked! The reality is actually very much the opposite: developer surveys consistently show that TypeScript is one of the rare tools that has consistently grown in both usage and developer satisfaction over time—unlike every other tool or framework in the front-end space! Given the surging popularity of the tool, it is fully to be expected that more posts expressing dislike for it will pop up here and there. If 99% of TypeScript users love it and 1% hate it, then when the language grows from having 10,000 users to 100,000 users you can expect the number of haters to grow from 100 to 1,000 as well. I hope that helps clarify the intent of the RFC and assuage some of your concerns! |
As an aside, it's really hard to understate just how important and invaluable TS is for Ember's own development process. I learned most of Ember core and Glimmer VM in the past 3 years, when large chunks of Ember (and all of Glimmer VM) had already been converted to TS. I honestly think it would have taken me the better part of a decade to get where I am today without types, and we would likely have had common and consistent regressions that could have been (and in practice, have been) prevented. Types are, IMO, absolutely crucial to maintaining a large codebase like Ember or Glimmer, and I think providing support for it will help large and small apps that adopt it enormously. All that said, I completely agree with the sentiments of the past few comments. JavaScript must still be supported as a first class citizen, and the learning path should not require any TypeScript. Support should not mean we regress in our current development experience. |
There's a lot here to take apart, so I'll try to break down my concerns to address each of these points. Ember interally already relies on TypeScriptThis sounds more or less to me like backwards rationalizing. It happens all too much in the field where a company adopts a technology like a SPA "framework", say ReactJS, then reasons that they've already committed to Facebook, so might as well start using the Flux architecture and lock in to Create React App's CLI Ember aims to solve this by providing a "one-stop-shop" approach where you kind of just "get everything out of the box". No need to think about routing (already there in the built-in router); no need to think about state management (ember data does that). Templates have their own separate files, keeping the logic separated from the markup. However, adding TypeScript muddies these waters; it won't be long before we sign off on getting rid of EmberJS may internally rely on TypeScript, but it doesn't need to; if this RFC merely asks to document TypeScript usage on the main EmberJS website, I have some qualms, but far less than if it becomes part of the standard blueprint. Types Solve EverythingTypes don't solve everything. As this isn't a debate on to TypeScript or not to TypeScript, strictly for documentation purposes, then sure, continue to use TypeScript internally. For documentation purposes and autocomplete, of course tooling will be better for a commercially-backed IDE that grandfathered TypeScript. To Tool or Not to ToolI agree that falling prey to the Bandwagon Effect often results in technical debt. Technical debt. A lof of us have settled on Ember because it deviates from the norm of "put everything in one file" and "pick your own router solution". A developer survey also shows that far more developers choose competing technologies like React and Vue because of their simplicity and ease of use (with a simple The discussion, rather, seems to focus on whether we should adopt TypeScript as a first-class citizen. For documentation purposes, this makes sense. From a beginner's perspective, it doesn't. My Bad Blood With TypeScriptThis discussion doesn't aim to talk about to to TypeScript or not to TypeScript, so I'll keep this to a minimum: I spent a year working full-time on a TypeScript project in Angular 2. At the end of it, it felt refreshing to return to writing "plain" JS in Ember where I didn't have to declare types after every variable or Every tool poses its merits and issues. In this case, TypeScript imposes yet another learning hurdle for newcomers. For that reason, I vote...
|
|
@srsgores I think the thing you may be missing is that this RFC does not propose changing the default Ember developer experience (and, in fact, it explicitly says we should not). As an Ember developer, you will not be required to think about TypeScript at all if you don't want to. Everything TypeScript-related would be opt-in, including blueprints and docs. Right now, a developer doesn't need to even be aware of TypeScript to use Ember. This would not change. |
|
This seems like all upside. The only downside is contributor burden, but I can assume that those people are already proponents of TS. So this doesn't seem controversial at all to me. |
|
Ember is the only major modern UI framework that does not support TypeScript. Hacking our way through JSDoc and This RFC is a move in the right direction, and while of course there will still be some gaps (eg: computed properties string-based DSL) - this RFC will extend the lifetime and viability of Ember as a framework, and improve developer satisfaction. p.s.: agree on added contributor burden, but without this change - there will be nowhere for them to contribute. 🦕 ☄️ |
|
@c69-addepar said:
TL;DR Before this RFC, the Ember TypeScript team, working loosely with the Ember Core Framework team, maintained a high level of TypeScript support in Ember. Many people make use of the extremely high-quality work of the Ember TypeScript team. Because of this, this RFC proposes that the Ember Core Framework team should take official responsibility for Ember's TypeScript support, and offer official stability guarantees around TypeScript support. I just wanted to clarify something, since this is a common source of confusion. Today, Ember apps can and do use TypeScript, using Together with the Ember TypeScript team, @chriskrycho (one of the authors of this RFC) has provided support for TypeScript in Ember for quite some time. The Notably, the Ember TypeScript team has participated in the normal Ember evolution process. In addition to providing a clear upgrade path for Their support includes Ember's core packages itself, as well as Ember Data, RSVP, and Ember Test Helpers (documented in their installation guide). In addition, That current status compares favorably to React, which also has externally maintained types (like Ember, you install the React types through an But don't get me wrong! In practice, React applications can successfully use TypeScript, and much of the React ecosystem treats TypeScript support as an important priority. This means that even though the React team does not maintain React's types, and even though there is no canonical guide for using React with TypeScript, we can say that React has first-class TypeScript support. There's no question about that. This RFC proposes that the Ember Core Framework team should offer semantic versioning stability guarantees for TypeScript, just as it does for Ember's JavaScript code. This goes beyond what React does, and by formalizing a definition for what semantic versioning will mean for Ember's types, goes beyond what most other frameworks do right now. |
Previous wording here could be (mis)read to take this as implying that our support is subpar or "second-class" despite its being hgih-quality and comparable to the state of much of the rest of the front end ecosystem (ahead in some ways, behind in others). This small revision clarifies that, by emphasizing the pieces we *want* to emphasize: making support an official policy, and bringing it within the Framework core umbrella.
|
It is very nice you published this RFC @chriskrycho and I can't +1 enough to take this direction, thank you. I cannot respond to all the messages I have read but for most of them I agree. Especially when it comes to reducing the gap with the other frameworks like React, Angular etc. Ton of work ahead will there be, if this proposition lands. |
|
This is awesome! I love this idea to have official support and guidelines + docs. On the site docs side of things I do wonder if there's some sort of babel transform that will let us strip out the TS types (AFAIK that's the main sytax difference between ES Next and TS at this point for what we'd use in the dock). |
|
@rtablada yeah, there are definitely some good options in that space—
I've intentionally left those as details to hash out in the associated RFCs, though! (Speaking of which: I’ll be opening one of the RFCs—not one of the docs ones!—in the next couple days. 😅) |
This RFC proposes a definition of [Semantic Versioning][semver] for managing changes to TypeScript types, including when the TypeScript compiler makes breaking changes in its type-checking and type emit across a “minor”release.(Note that this RFC addresses *only* type checking and type emit, *no t* the “transpilation”mode of the TypeScript compiler.) [semver]: https://semver.org While this RFC is being authored in the context of Ember.js’ [adoption of TypeScript as a first-cl ass supported language][RFC], its recommendations are intentionally general, in hopes that th ese recommendations can be widely adopted by the broader TypeScript community. [RFC]: emberjs#724
This RFC proposes a definition of [Semantic Versioning][semver] for managing changes to TypeScript types, including when the TypeScript compiler makes breaking changes in its type-checking and type emit across a “minor”release.(Note that this RFC addresses *only* type checking and type emit, *no t* the “transpilation”mode of the TypeScript compiler.) [semver]: https://semver.org While this RFC is being authored in the context of Ember.js’ [adoption of TypeScript as a first-cl ass supported language][RFC], its recommendations are intentionally general, in hopes that th ese recommendations can be widely adopted by the broader TypeScript community. [RFC]: emberjs#724
|
Re-reading these (TS related RFCs) and have a question about this @wycats comment:
Has TypeScript itself stabilized enough for us to do this? I observe everyone already being stretched pretty thin as it is. To be clear I don't object to the idea of it; I am concerned about the practical implementation. I think it would call for some more strategic conversations to happen first. |
|
@MelSumner I can't speak to the TS roadmap personally, I'm not really keeping updated with new features and things they're focusing on, but anecdotally I can say that in the past year or so upgrades have gotten much better overall. We have experienced much less churn in the Glimmer VM and Ember codebases, and it does feel like there's more stability and changes are now more incremental. I also think that this is not exactly a zero-sum situation. Adding support for TS will mean we need to consider types when we build and maintain APIs, but we already do that for all new APIs and most existing ones, just not publicly. There's also a pretty large amount of duplicate work by the Typed Ember team and community to maintain the Definitely Typed types in parallel with our internal types. Every API is duplicated currently, and oftentimes there are mistakes that lead to even more maintenance cost overall. Adding support for TS in the framework would mean that those community members could start contributing to the main codebase instead of the duplicate types, so we would effectively have more core contributors overall to help us keep up with the additional work load. I think the biggest area of risk is if we need to maintain multiple TypeScript versions for a long period of time, due to some breakage from TS. We can minimize this risk, but it will always be present, and that could add a lot of maintenance cost. That's why I think the rolling-support-window support policy makes the most sense for Ember itself. This would ensure our users would always be able to upgrade TS independently of Ember, from LTS to LTS, and that we would at most have to maintain 1-2 old TS versions for a finite window of time before being able to drop support. This would be much better than the current state of types for TS developers, and would minimize the impact TS support would have on the core team and development process. |
|
@pzuraq okay, that makes sense; thanks for clarifying! 👍 |
|
This has been lingering a little bit, but the core team finally discussed it at todays meeting. We are all in favor of moving forward here, and are moving this into Final Comment Period. 🎉 |
|
I've been using I can't +1 enough! |
RFC #724 originally intentionally excluded template type checking via Glint from its designation of "official support" for Ember. However, in the time since the RFC was authored, there have been two significant changes: 1. Glint itself has matured significantly, with no known major issues at this time (though plenty of polish still to be done). 2. The *major* design issues in Ember needed to unblock Glint have been resolved: - resolution of template identifiers (components, helpers, and modifiers): RFC #779 - a Glimmer Component type signature which exposes information about the blocks and the target for `...attributes`: RFC #748 Although there remain a number of smaller design questions to resolve, this is sufficient for us to treat type-checked templates as a viable part of our story, and given *viability*, we think this is *necessary*.
Advance RFC #724 "Official TypeScript support" to Stage Ready for Release
Advance RFC #724 `"Official TypeScript Support"` to Stage Released
TypeScript has become a key part of the front-end development ecosystem over the past several years, and powers many of the best developer experiences in the broader JavaScript ecosystem. Ember was a relatively early TypeScript adopter for its internals, and there is widespread usage in the ecosystem with community support from the Typed Ember team, but to date Ember has not provided “out of the box” or official support for authoring apps or addons in TypeScript.
This RFC declares our intent to officially support TypeScript as a peer to JavaScript, in a way which makes the developer experience better for all Ember developers. It outlines the key constraints and goals for the effort, details a roadmap for accomplishing those goals, and provides the following definition of official support (from the Detailed Design: Defining Official Support section in the RFC text):
Rendered Text
Note: this RFC is focused on the question of whether we should adopt TypeScript, and if so how. It is not, however, the right RFC for discussing the specific concerns it identifies. Discussion should focus on: