Could this RFC prevent innovation?

Ayc0 commented 2 years ago

Syntax changes in TS

TS is changing often, sometimes those changes are related to the type system itself and so are internal and don't impact the syntax (like with the 4.8 generic change related to {}).

But others are directly related to the syntax and how the TS code gets parsed, and those happen quite often:

in 4.9, TS is planning on adding a new satisfies operator – link
in 4.7, TS added the possibility to have variance annotations in generics – link
```
type Getter<out T> = () => T;
```
in 4.7, TS added instantiation expressions – link
```
const makeHammerBox = makeBox<Hammer>;
```

I'm a bit worried that having a fixed syntax in TC39 will prevent TS from expanding further (or that if it does, we'll still have to transpile the code to be able to target a version accepted by JS).

Also, TS can have breaking changes in its syntax if they want to, but JS cannot. For instance, if we decide to ship both types and JSX in the EcmaScript spec, we could have overlaps between those 2 (TS at the moment requires to use either commas <T,> or extends <T extends any> when using generics in TSX files), but we won't be able to retroactively change the spec.

Transformers

Also, as mentioned in README:

As mentioned elsewhere, some constructs (like enums and namespaces) have been set aside with the option to propose them separately in TC39.

And also:

In type systems today, a declare keyword can precede bindings such as variable, function, and class declarations. (...) At the moment, this proposal does not reserve space for ambient declarations, but it is an option.

So it means that people will still have to run transformers on their codebase to generate valid JS code.

Cost

And as mentioned in https://github.com/tc39/proposal-type-annotations/issues/43, transpiling code is an operation done once at build time, that now all clients will have to do at each runtime:

Therefore you are offloading a one time cost (server side) to N billions of clients times.

Conclusion

So all those considered, I'm wondering if:

this RFC could prevent innovation within TS (and other type systems),
this RFC won't actually solve the need of transpiling the source code,
this RFC could be harmful in general for performance.

orta commented 2 years ago

I think you've maybe mis-interpreted the proposal, the proposal is not "move all of typescript syntax into JS". For example, right now operators like satisfies or the expression instantiation concept would not be allowed - the proposal would allow for a large amount of TypeScript code to run in a JS engine, but not all.

This puts the decision on the typescript team to find ways to fit those sort of problems into the syntax hole provided in the spec. E.g. { a: "str" } as satisfies instead of allowing a new arbitrary keyword.

Andrew-Cottrell commented 2 years ago

So far as I understand this proposal, I believe the current idea is to introduce an alternative commenting syntax that is intended to be a less verbose equivalent to JSDoc annotations as currently supported by TypeScript and Closure Compiler.

If my understanding is correct, there would not be substantial impact on TypeScript as a distinct language to JavaScript. Instead, this proposal would enable a less verbose method of annotating JavaScript with types that could be parsed by a type-checker, which may make it easier to work on projects that use both JavaScript and TypeScript source files. Non-type-checking JavaScript engines, such as those found in web browsers, could treat the new type annotations as if they were comments and ignore them during parsing as they do with other comments.

My conclusions are that

the addition of a new commenting syntax to JavaScript would not prevent innovation in other languages
transpiling would continue to be required if there were a need to run non-JavaScript code in a JavaScript-only engine
the addition of a new commenting syntax should not be harmful to performance and minification will continue to make sense for network-transmitted JavaScript (i.e., when intended to be run in a web browser).

Ayc0 commented 2 years ago

For example, right now operators like satisfies or the expression instantiation concept would not be allowed

That's what's worrying me a bit: having a fixed syntax could either:

fix the syntaxes supported by TS (sort of what you're mentioning with { a: "str" } as satisfies)
or require us to transpile TS to a "standard JS with types syntax"

I'm a bit worried that having a fixed syntax in TC39 will present TS from expending further (or that if it does, we'll still have to transpile of code to be able to target a version accepted by JS).

Ayc0 commented 2 years ago

So far as I understand this proposal, I believe the current idea is to introduce an alternative commenting syntax that is intended to be a less verbose equivalent to JSDoc annotations as currently supported by TypeScript and Closure Compiler.

Thanks for the pointer 🙇. I didn't understand that when I read the README, my bad.

With a fully different syntax (like the JSDoc for TS, or the Closure one, or the Flow one), I think that most of the issues I raised will be resolved.

That said, having a syntax in which types are in comments seems to be against the aim of this proposal, so I'm a bit surprised that this seems to be the direction we're going with:

The aim of this proposal is to enable developers to run programs written in TypeScript, Flow, and other static typing supersets of JavaScript without any need for transpilation, if they stick within a certain reasonably large subset of the language.

Andrew-Cottrell commented 2 years ago

That's what's worrying me a bit: having a fixed syntax could either:

fix the syntaxes supported by TS (sort of what you're mentioning with { a: "str" } as satisfies)

or require us to transpile TS to a "standard JS with types syntax"

I'm hoping the type-syntax will not be fixed so that we can use choose from various type-checkers that support different type-syntax. The main benefit, as I see it, is that it would be easier to write type-checked JavaScript (as is already possible using Closure Compiler) and it will also be easier to work on projects that include both JavaScript and TypeScript (or JavaScript and Flow) source files. Those using TypeScript or Flow only for the benefit of type-checking could choose to switch to type-checked JavaScript if they would prefer to avoid transpiling.

However, this proposal is only at Stage 1 and the README hasn't been updated for quite a while, so it's quite possible my understanding is out-of-date, or the proposal might change significantly before it reaches Stage 3.

Ayc0 commented 2 years ago

Thanks @orta and @Andrew-Cottrell for the comments!

As the current state of the readme is most likely gonna change (as also per the "Details will change in the coming days" in the readme), I'll close this issue here and look for new updates in this RFC.

As a huge fan of TS myself, I'm really interesting in seeing how types could be implemented in the standard ECMAScript spec in the future!

hinell commented 1 year ago

I'm a bit worried that having a fixed syntax in TC39 will prevent TS from expanding

There is nothing to worry about. At that pace that TS currently has it won't stop evolve and I can tell you at some point nobody would be able to completely master it. The TS bloat is so severe few really are able/wanting to use all its features.

tc39 / proposal-type-annotations