3 ms·

The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset o

The last point you mention actually makes me think this is probably a harmful change, that could have a chilling effect. People only wanting to use the subset of TS that runs as JS, could hamstring future TS features, as well as limit current features usage for no good reason.

klodolph 4y ago
I have the exact opposite opinion. TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed. Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step. This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes. My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design. TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.
- redox99 4y ago
  TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features. TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types. Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
  - klodolph 4y ago
    TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language. That’s why enum should be avoided in TS or added to JS. I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
    - redox99 4y ago
      > we already have other languages with new features Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers). TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations. So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?
Latty 4y ago
That ship has already sailed, the TS team have been clear about not wanting to add features that aren't purely type-level for a long time. The suggestion issue template has a checklist requiring you check off that "This could be implemented without emitting different JS based on the types of the expressions" and telling you it realistically won't be implemented if not.
- redox99 4y ago
  Well that's a pity. I find annotations and enums very useful, and wish we had more stuff like that.

klodolph 4y ago

I have the exact opposite opinion. TypeScript used to have more sugar, and that sugar had been removed and merged with the equivalent ES functionalities. Dig through old TS versions and you’ll find obsolete syntaxes or semantics that have been removed. Just to pick an example, TS had class before JS. IMO the ideal scenario here is that TS is just type annotations on top of JS, and any features you use which aren’t universally available, you polyfill/transpile as a separate step. This means TS is just types, and your transpired/polyfills are just transpilers/polyfills. To achieve that, TS classes are modified to match JS classes. My sense is that TS will not add new stuff not in JS any more. It’s simply not a direction TS is going. I also get the sense that enums are a mistake in TS’s design. TS in some sense is a reaction to the lessons learned from its predecessors, like CoffeeScript.

redox99 4y ago
TS replacing it's own custom features if JS implements them is the correct move. But in my opinion they shouldn't hold back from adding features if they are good features. TS goal IMO should be to offer the best developer experience, while maintaining interoperability with the JS ecosystem. Not just limiting themselves to types. Why do you think enums are a mistake? Enums allow you to have autogenerated mappings from symbols to integers. You can't do that with types as you showed in your example.
- klodolph 4y ago
  TS should absolutely hold back from adding new features that are not in JS. That’s TypeScript’s niche—we already have other languages with new features, TypeScript works better as a typing system and nothing else on top of an existing language. That’s why enum should be avoided in TS or added to JS. I can understand why people want TS to be a “better” language, but these days, ES is pretty good and a major part of TS’s success is that it follows JS semantics almost everywhere.
  - redox99 4y ago
    > we already have other languages with new features Not languages that can interoperate with JS the way TS does (except for flow and similar type checkers). TS success is that it's a superset of JS (unlike say CoffeScript). So you can throw some JS and it will be valid TS. The point of being a superset is that you can add new stuff. Types, enums, annotations. So the only argument why enums are bad except for that it's not in JS? Why does it matter, just because a JS developer has to learn more things if they switch to TS? The whole argument hinges on the premise that TS should not add anything that JS doesn't have except for types, but why is that?

Latty 4y ago

That ship has already sailed, the TS team have been clear about not wanting to add features that aren't purely type-level for a long time. The suggestion issue template has a checklist requiring you check off that "This could be implemented without emitting different JS based on the types of the expressions" and telling you it realistically won't be implemented if not.

redox99 4y ago
Well that's a pity. I find annotations and enums very useful, and wish we had more stuff like that.