Clarity and coherence

[nweldev]

@giltayar « I want all that TypeScript code that developers write today to become JavaScript. If we don't do that, I am afraid we could lose control of the language to third party type checkers. » - https://github.com/giltayar/proposal-types-as-comments/issues/43#issuecomment-1068340281

I believe this statement helps to better understand the purpose of this proposal and is coherent with most of the arguments in favour of it. Consequently, the introduction on "adding type annotations that are ignored by the JavaScript engine" seems misleading.

I, therefore, propose to:

1. clearly state this idea in the introduction of the proposal itself for more clarity
2. rewrite the FAQ for more coherence.

Coherence problem

This goal seems to contradict some previous statements and parts of the proposal itself.

For example:

« This proposal does not propose to copy the TypeScript grammar as is. » - https://github.com/giltayar/proposal-types-as-comments/issues/43#issuecomment-1067144818

and the "Should TypeScript be sanctioned as JS's official type system?" section of the FAQ:

« Making this proposal be only about TypeScript can hamper this effort. Amicable competition in this space would be beneficial to JavaScript as it can enable experimentation and new ideas. »

Counter-argument

The long list of TypeScript specificities in the proposal itself seems to confirm that "TC39 should follow TypeScript" is the main idea behind this proposal.

Yet, the FAQ repeatedly underlines that the standardization process shouldn't interfere with TypeScript development (especially in "Should TypeScript be standardized in TC39?")

IMO putting these two ideas together would give a privileged role to TypeScript contributors and, in the end, Microsoft. I say that with nothing against Microsoft or TypeScript in particular. But it would go against fundamental principles of open standards development (especially that decisions are made with equity and fairness among participants).

Of course, I also understand that this proposal tries to be as generic as possible, taking "type checkers, such as Flow, Closure, and Hegel" into consideration. I don't know much about them, so I may be biased. But still, the whole proposal and the related discussions seems strongly tied to TypeScript, with adaptations being made after the fact.

[benjamingr]

The long list of TypeScript specificities in the proposal itself seems to confirm that "TC39 should follow TypeScript" is the main idea behind this proposal.

This is a strawman and pretty agressive IMO. This proposal explicitly does not choose TypeScript but enables evolution in the comment space.

(disclosure: I work for Microsoft but not on TypeScript and I have no incentive (other than volunteering) collaborating on this proposal (my boss has no idea I'm working on this in my free time :D)).

This proposal does however have people from multiple to-js languages (like flow). Note TypeScript itself is also open source but that's besides the point.

In fact a big part of the proposal is to not pick TypeScript or some other language to enable userland evolution of these languages in the future.

[nweldev]

@benjamingr Thanks for the feedback. Sorry, I don't see how it is a strawman, and it wasn't my intention at all to sound aggressive. Would you have some suggestions on how to rephrase that? Or do you feel like my point is "aggressive" in itself?

I see what you're saying here. But in this case, why do comments and the proposal itself always refer to TypeScript? It seems like this proposal is starting from TypeScript and then try to make it generic, instead of starting from a problem statement to solve.

[theScottyJam]

It seems like this proposal is starting from TypeScript and then try to make it generic, instead of starting from a problem statement to solve.

This certainly seems like the case to me. So, while a bunch of the features proposed in the README look typescript-specific, and some of the tentative grammar choices they're currently running within their proposed grammar file has even more TypeScript-specific syntax, I hope they find good ways to generalize this more and more until we find a syntax space that's flexible enough for current and future needs of different type-checkers.

I don't have an issue with using TypeScript as a starting point. It's a pretty solid starting point, considering the success it already has. I just hope we don't also view it as the endpoint, as doing so could greatly restrict our ability to generalize the syntax for other type-parsers (we may have to be willing to lose some compatibility with TypeScript syntax in order to provide syntax rules that are more generic and flexible). Hence, I don't agree that this should be the problem statement of this proposal:

I want all that TypeScript code that developers write today to become JavaScript. If we don't do that, I am afraid we could lose control of the language to third party type checkers.

This problem statement that the proposal already has seems to do a good job at articulating the goal that I see:

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.

[benjamingr]

@benjamingr Thanks for the feedback. Sorry, I don't see how it is a strawman, and it wasn't my intention at all to sound aggressive. Would you have some suggestions on how to rephrase that? Or do you feel like my point is "aggressive" in itself?

The proposal explicitly does not work for only TypeScript while acknowledging TypeScript is currently the biggest type system in use in the ecosystem and is fairly popular. There are people from different type systems and checkers (e.g. flow) working on this proposal.

The FAQ states:

Making this proposal be only about TypeScript can hamper this effort. Amicable competition in this space would be beneficial to JavaScript as it can enable experimentation and new ideas.

So saying "TC39 should follow TypeScript" is the main idea behind this proposal." directly conflicts with the FAQ explaining why not only is this not suggested but in this proposal's opinion it would be a bad idea.

But in this case, why do comments and the proposal itself always refer to TypeScript? It seems like this proposal is starting from TypeScript and then try to make it generic, instead of starting from a problem statement to solve.

Probably because the primary author and most contributors have the most experience in it and write for an audience which probably also has the same.

There has been active effort reaching out to other type systems and tool authors and a lot of feedback gathering on what works and doesn't for other type systems. The idea is to enable evolution and simplify developer workflows.

[kee-oth]

@noelmace I share your sentiments 👍

Starting from the point of "Let's make TypeScript and Flow code work in the browsers" definitely starts off this proposal as favoring those systems. So this proposal is skewed from the beginning. Regardless of any "We just want this proposal to make any type system work" verbiage used. That's just not the actual goal. The real goal is figuring out a way to make TypeScript and Flow work and other type systems are welcome if they play by the rules that TS and Flow set.

If the proposal just started with "Let's make a type system that works for JavaScript" and only mentioned TS and Flow as prior art, it'd be a lot healthier of a proposal with less bias, imo.

[bicknellr]

One of @giltayar's comments from issue 43:

Out of scope of this discussion, I know, but for me the question is not just a question of cost. It goes to the "soul" of JavaScript: do we want it to be a language that HAS to be run with tools and can't just run "natively"? I for one, do not.

In a way, this proposal looks towards both the future and the past. Towards the future, because the community has (arguably) decried that the future has some typing in it. And to the past, when newcomers could just take some code and run it, without needing to run complex toolchains that they (and, frankly, most js developers) cannot comprehend or configure.

So even if the cost is not "justified", I would still want types incorporated into native JS.

And more recently in that same issue:

@PSanetra that is where we differ. I think it is necessary to change the language, so as to mend the existing rift we have between developers who write TypeScript and runtimes that execute JavaScript. I want all that TypeScript code that developers write today to become JavaScript. If we don't do that, I am afraid we could lose control of the language to third party type checkers.

I find these comments really confusing because I agree very strongly with the values expressed there, but the idea of shutting out any future possibility of an enforceable type system in JavaScript by permanently discarding the related syntax space seems to run directly against those values. In a situation where users have already resigned to using a build step - a necessary condition for finding this proposal useful - making the input to that build step valid but meaningless syntax on the other side does not help remove that build step from the workflow. In fact, it would guarantee that build step could never be removed so long as that user demands that syntax have meaning somewhere in that workflow.

To be clear, I'm really glad to see new momentum behind solving this problem! However, I don't think that the popularity of existing third-party type systems constitutes a pressing need to set an artificial ceiling on the current or future fitness-for-purpose of JavaScript in isolation. That effort would be much more valuable if put towards working on an enforceable type system. I don't follow the implications in the new sections in the README and the discussion in https://github.com/giltayar/proposal-types-as-comments/issues/45 that the only two options are 'some / all values are type checked at each use at runtime' and 'no type system whatsoever'. It seems like a false dilemma that ignores a space of options that might not have to incur ongoing costs of asserting proper types at every use. (Would the semantics of an acceptably performant type system be looser than existing third-party type systems? Maybe. I don't think that's sufficient reason to discard serious exploration of the idea though.) Despite the fact that finding a standardizable type system for JavaScript will definitely be difficult and will definitely clash with existing third-party type systems throughout the standardization process, I still think it's possible and that the web platform will be much better off for having gone through the trouble.

---

(edited to add grouping quotes)

p.s. I also want to clarify that specifically 'making all TypeScript be JavaScript' isn't the type of value I'm talking about. I mean more broadly the idea of noticing that tools for solving a particular problem (type safety) have become very popular and that this means that there's likely a gap in the platform itself that needs to be addressed.

[gkz]

There are people from different type systems and checkers (e.g. flow) working on this proposal.

I want to clarify (as someone on the Flow team) that I do not think this is an accurate statement. We are no more involved than anyone else commenting on this repo. We have made some comments but they have not been addressed (e.g. #91) - the proposed grammar is TypeScript specific. (So preferably do not use our team name in an endorsement of this proposal).

[simonbuchan]

Would it make you happier to know I'm working on (as in actually implementing into a JS implementation) a "most general safe grammar" as an upper-bound to the current "least general minimally useful grammar" that is currently provided, so the committee can find a middle-ground they feel happy with? I hope to have something to show in a day or two, if not complete.

[theScottyJam]

If the proposal just started with "Let's make a type system that works for JavaScript" and only mentioned TS and Flow as prior art, it'd be a lot healthier of a proposal with less bias, imo.

You know, I think this makes a lot of sense. Instead of starting with TypeScript and generalizing when it's possible/convenient, it probably would have made more sense if they started with a blank slate and a list of prior art, then tried to find different syntax constructs that would make everyone happy.

I certainly believe the problem statement is strong enough to bring them to stage 1. But, normally, you'd also least have a tentative solution that's able to fulfill the problem statement. I don't feel like they even have that here, which scares me a bit (it gets close, but it seems to be prioritizing something different than what the problem statement prioritizes).

The README's main goal states that they want to provide syntax that would make all type-systems happy, but their proposed solution is a bunch of TypeScript-specific syntax that happens to sometimes overlap with the syntax of other type-engines, and the only flexibility they're currently providing is the fact that you can use parentheses (or brackets) in a type definition to add arbitrary content (e.g. let x: (whatever you want)). This solution doesn't fulfil the problem of "finding a generic syntax for all type systems to enjoy", instead, this solution is "Stick TypeScript in JavaScript, and when convenient, add a bit of flexibility so other type-engines can try and use it as well". No wonder so many people finish reading the README thinking that this is exactly what the proposal is trying to do, because that's what the solution being proposed is doing. And, I think this has generated a lot of confusion in these issues as well, where we're just uncertain what the proposal is striving to accomplish.

So, which is it. Is the main goal to provide flexible syntax for everyone to enjoy, as the objective and FAQ suggest, with the secondary goal of trying to support TypeScript's existing syntax as-is? Or is the main goal to stick TypeScript syntax into JavaScript as-is, and a secondary goal is to be flexible, as the proposed solution seems to suggest. You can't do both 100%, we're going to have to make sacrifices in one of these objectives in order to better fulfill the other objective.

Now, again, I get it, you don't have to have a great, concrete solution presented to make it into stage 1. But, still, it would be nice if the proposed solution aligned better with the stated problem. Either that, or we adjust the stated problem if the primary goal really is to get TypeScript syntax into JavaScript as-is.

[simonbuchan]

@theScottyJam Not sure if it was the intention, but I found the minimal grammar really useful when generalizing.

[lillallol]

@benjamingr

I would like to kindly remind you that you stated [1]:

There are people from different type systems and checkers (e.g. flow) working on this proposal.

The long list of TypeScript specificities in the proposal itself seems to confirm that "TC39 should follow TypeScript" is the main idea behind this proposal.

This is a strawman and pretty agressive IMO.

and you got the following response [2]:

I want to clarify (as someone on the Flow team) that I do not think this is an accurate statement. We are no more involved than anyone else commenting on this repo. We have made some comments but they have not been addressed (e.g. https://github.com/tc39/proposal-type-annotations/issues/91) - the proposed grammar is TypeScript specific. (So preferably do not use our team name in an endorsement of this proposal).

You have yet to clarify the situation.

---

Note TypeScript itself is also open source

There is no guarantee that something that is now open source will also remain like this in the future. And nobody will follow any of the myriads of open source forks that will occur if TypeScript goes closed source.

The solution to:

we could lose control of the language to third party type checkers

is definitely not:

I want all that TypeScript code that developers write today to become JavaScript. If we don't do that, I am afraid we could lose control of the language to third party type checkers.

which by the way is stated by the creator of this very repo, and among many others like [3][4], proves the gist of the OP, and makes arguments like:

This is a strawman and pretty agressive IMO.

pretty much invalid.

In fact it is the actual problem and it will definitely kill:

Amicable competition in this space would be beneficial to JavaScript as it can enable experimentation and new ideas.

If we want to keep all the type checkers happy then we have to make sure the new syntax that is introduced does not require breaking changes to other type systems. @simonbuchan It is naive to believe that there is a:

minimal grammar

that will satisfy everyone. It will simply not be useful, even if it does exist.

(@theScottyJam maybe the next paragraph will make more clear the benefits of separation of intend and implementation) The solution that will satisfy all type checkers is actually reserving 0 syntax from JavaScript and this can only be achieved by sticking to the best practices and separating intend from implementation, (i.e. .ts,.fl, .etc, files that will contain only types and no concretions), importing types via already existing comment syntax (and this actually is the only place that has to be standardized among all type checkers, and will not require breaking changes) and discontinuing attempts of type checkers to be super sets of JavaScript, by discontinuing compilation from .ts,.fl,etc. to .js. This will inevitably make type checkers act as a complement to JavaScript, and not as super-sets. It will also promote loose coupling of the source code with the type system used (.js files will have nothing specific to the type system used) and hence easier migrations and hence people will feel more comfortable using other type systems, since they will just need at most two files with types (a declaration file written by hand describing the public api and a file for the private api), and hence amicable competition. Arguments like verbosity, ergonomy and less features that are used in this proposal against what I suggest, are mostly because:

But in this case, why do comments and the proposal itself always refer to TypeScript? It seems like this proposal is starting from TypeScript and then try to make it generic, instead of starting from a problem statement to solve.

Probably because the primary author and most contributors have the most experience in it and write for an audience which probably also has the same.

and are actually proven to be exactly the opposite under investigation.

So to conclude the starting point of the proposal is pretty biased in favor of doing things a certain TypeScript way. You people are inventing at least three more new ways to add comments... that are actually not supposed to be used as comments.

This proposal... enables evolution in the comment space.

This is as true as calling the following extensions to the syntax of JS:

1. import type {IMyType} from "./some/where.js";

2. const myFn : IMyType = () => {};

3. function fn(<T>)() {}

comments. Which I honestly find absurd and only further proves the point of the OP.