> Type erasure is good! It means JavaScript project can consume TypeScript projects without any knowledge of TypeScript. It's just emitted JavaScript. This does not mean you can't emit the type information separately in a consumable lookup table that's separate from the code. The lack of this type information means we use esoteric libraries which ultimately pollute the JavaScript with all the convoluted typing working arounds... soo... type erasure has defeated the purpose of type erasure. It's a second order effect, where the design goal defeats the design goal. :(
I think the author misunderstands the design goals of TypeScript. The goal isn't to have pristine, beautiful JS code with no complexity, the goal is to have the runtime semantics of TypeScript be identical to the runtime semantics of JavaScript. Barring the regretted exception of enums, TypeScript can be converted to JavaScript by simply stripping type annotations. That's the design goal, and that goal is not in conflict with itself.
The ecosystem that has built up around TypeScript depends on complete type erasure, and much of it would evaporate if this wish were granted. TS support in ESBuild, Deno, and Bun would become nearly impossible, because each would need to re-implement all of tsc in their respective languages, while right now they just need to maintain their own simplified parsers.
On the other hand, the convoluted libraries that OP bemoans are perfectly compatible with all of these tools, because they're implemented in user space.
There are plenty of ways to emit runtime type information statically without a runtime. `keyof` could statically convert to the list of keys in a class. Hell, even typescript classes could do what ES6 classes do and initialize class keys to undefined. Currently, typescript classes erase all keys unless explicitly defined. Object.keys() on a newly instantiated typescript class without set members will return nothing, while an ES6 class will return all of the keys. Just an option in tsconfig.json to convert TS classes to ES6 classes (or just allow ES6 classes to exist at the same time in Typescript) would make some code generation WAY easier.
Or some kind of syntax to emit the name of a type as a string. Currently, if you run `typeof foo` it will return the type as a string. If you could have a static version of that, like `tstypeof foo`, or with a class:
class Foo {
bar: string;
};
console.log(tstypeof Foo::bar) // or something less C++-looking; compiles to "string".
then it would be killer. This could break compatibility if you change the type of a field and a compiled client using the code were to expect "string" when it's been changed to "number". But I'd rather live in that world than the one we live in now
Just some basic RTTI would make a lot of ugly codesmelly boilerplate Typescript code evaporate instantly.
I think the author misunderstands the design goals of TypeScript. The goal isn't to have pristine, beautiful JS code with no complexity, the goal is to have the runtime semantics of TypeScript be identical to the runtime semantics of JavaScript. Barring the regretted exception of enums, TypeScript can be converted to JavaScript by simply stripping type annotations. That's the design goal, and that goal is not in conflict with itself.
The ecosystem that has built up around TypeScript depends on complete type erasure, and much of it would evaporate if this wish were granted. TS support in ESBuild, Deno, and Bun would become nearly impossible, because each would need to re-implement all of tsc in their respective languages, while right now they just need to maintain their own simplified parsers.
On the other hand, the convoluted libraries that OP bemoans are perfectly compatible with all of these tools, because they're implemented in user space.