Cost benefit analysis

[LifeIsStrange]

A non erased javascript support for type would enable features such as type reflection and reified generics, which improve the expressivity of the language and make it more on par with modern languages. However, currently this proposal is not making any use of the types despite them needed to be parsed or at least properly ignored.

The remaining stated benefit is that this support might (to be defined) reduce transpilation needs for e.g TypeScript. However if I am understanding correctly, in all intellectual honesty this proposal should state that it is not a free lunch and that the cost of transpilation is offsetted to the Javascript parser/interpreter, which must now properly ignore those unused type informations. Therefore you are offloading a one time cost (server side) to N billions of clients times. While support for runtime type reflection might justify such added cost, without it this proposal seems like a net performance loss for end users. There already exist plenty of fast server side TS transpilers such as SWC, esbuild, etc which make the proposal benefit seems even less interesting. What do you think about this?

[hinell]

I agree with @boehs and hope this won't be merged as well. My two cents:

• TS evolves fast; there is zero chance that the spec will be in sync with all TS features;
  • neither others would be able to do the same; it's a massive headache
  • TS has quite complicated and flawed typing attribs - we can't allow this "cancer" to spread
• We can't allow Microsoft to dominate and steal web success by sneaking into JS syntax spec
• ZERO benefit for final users
• This aims to do the job that dev tooling can do; no need to bring this to clients

[shaedrich]

@fabiospampinato - yes, but this would also allow you to remove an entire step from your tool-chain. A step many consider to be particularly laborious to deal with. I like the idea of types, I even like the idea of Typescript (incrementally), but the Typescript compiler often annoys the hell out of me.

You can't have your cake and eat it, too 😂 You want functionality (type checking) just isn't part of the language (JS), so there's (for good reasons) just no way around using tooling. That's the bargain.

Also, putting the "I went away from JS to TS, now I have trouble with TS, so JS must fix this for me" on the non-TS JS developer community just doesn't seem right.

Most standard TypeScript syntax is supported, and reaching out to .d.ts files would still be feasible for cases when syntax cannot legally fit the constraints we're looking at.

That would beg the question: Who would write these files?

• The TS compiler, automatically: I thought, we wanted to get rid of it
• The developer, manually: So, now you have to write both JS and TS, depending on which is supported and knowing which is supported, as well as possibly migrating existing codebases to function without tsc. Sounds like PITA.

define that syntactic space within JavaScript for type-systems and other tools to safely exist in a way that engines can know how to ignore them.

So, JS's future to excel in ignorance? Not sure if that's something, I'd pride myself with. There have been other proposals (for example, compartments, parser augmentation, import attributes, etc.) that would have more benefit to the JS community specifically as a whole, not just TS devs who don't like TSC. Might be interesting to @giltayar

A browser which knows how to strip TypeScript types for example would have to keep up to date with the TypeScript implementation which could add new syntax every quarter.

It sounds like a terrible idea that every time, TypeScript adds a new syntax, that isn't stripped away by the specs of the scope this proposal,

• the browser should adjust itself to also strip these away, practically circumventing ECMAScript standards and potentially resulting in differing browser support
• however, if this was to be passed through the ECMAScript standardization process each and every time, this would be time consuming and would make the two languages heavily dependent on each other.

Additionally, every time, TypeScript adds new syntax, everyone who works without the TS compiler now has two options:

• use the compiler again to be able to use the new syntax
• wait for the implementation to use this (so, you first update your TS version and then wait for the browser to be updated as well)

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. […] without needing to run complex toolchains that they (and, frankly, most js developers) cannot comprehend or configure.

JS can still run without any toolchains. It is TS who can't. Stop making TS problems JS ones.

such a specification wouldn’t be able to make breaking changes, which TS needs to do with some regularity.

Well, client-side scripting is built around stable back compatibility. This probably shouldn't be circumvented.

mend the existing rift we have between developers who write TypeScript and runtimes that execute JavaScript.

So, TS opened the rift but JS must close it? I guess, you've got the cart before the horse here.