On its face this is (to me) an obvious, and obviously good, proposal in the abstract. So obvious I’m astonished it’s taken so long to materialize. I’ll leave it to the proposal and other advocacy to justify that: I’m just noting my bias for anyone who may misinterpret what follows, because I have some concerns about the details.

1. While care was obviously taken to be type system agnostic, and while TypeScript is obviously the current incumbent, I think there could be more of a sign of collaboration with Flow, Closure and Hegel.

1a. They’re notably mentioned but conspicuously no one from those projects is listed as authors/champions. This suggests to me that they weren’t (substantially) consulted in drafting the proposal, which implicitly weights the proposal’s details in TypeScript’s favor if only by inertia.

1b. There’s surprisingly little “give” in terms of the few minor differences between Flow and TypeScript. I’ll grant the potential reservation of `opaque type`, but strongly suspect that’s because opaque types are already under consideration as a TS feature.

2. Omission of certain runtime-affecting constructs is certainly pragmatic, and not omitting them almost certainly a deal breaker for the proposal. But, it’s also quite likely to fragment TypeScript, effectively deprecating those parts of the language (which I’m sure the TS team would prefer to do explicitly, but well, that’s a much heavier lift).

3. This limited subset of TS syntax almost certainly is a real superset of JS, but there are some parsing disambiguation complexities to consider, particularly for type parameters on functions as well as (if ultimately included) function overloads and bare property modifiers. This also affects runtime performance, particularly at load time which is critical.

4. Omitting JSX makes sense in the current state of the world, but does it make sense for the goals of this proposal?

4a. JSX usage outside of TS has an almost totally overlapping motivating problem: the need for a build step. It doesn’t fit the proposal now, because JSX (usually) has runtime semantics, but they’re unspecified without build time configuration.

4b. Of all things that will fracture TS, this one is irreconcilable. I’m honestly surprised it’s even being considered by anyone on the TS team.

4 (conclusion). Given 4a/4b, JSX almost certainly should be a separate proposal, but I think it should seriously be considered as a potential prerequisite.

5. The goal of rapidly evolving TS and conservatively evolving TC39 is a balance that probably can be struck, mainly because the TS team has been incredibly good at keeping their syntax and semantics aligned with standards. But baking type comments into the language with a variety of new syntax blocks that syntax from being used for other proposals. For type-only syntax that’s obviously not a huge deal, but I’m imagining a fair bit of push back on reserving, say, the colon character in function positional arguments.

Probably more I haven’t thought of. And I want to reiterate I think this is a great idea in the abstract. I want to see it succeed. If the champions or any of the TS/Flow/Closure/Hegel teams, or anyone else here thinks any (or all) of these concerns should find their way into issues on the proposal repo, please feel free to copypasta or ask me to do same.