hinell
commented
1 year ago 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
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?