TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary.
This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version.
The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though.
Which exact part of TS do you want to be built into browsers?
There's still non-const enums generating runtime code
I think it would be huge if some future nodejs/web browser can parse native TS so we no longer need to deal with the mess of dev tools like ts-node and babel and wonder why some folder structure or sourcemap is not working
TypeScript is designed in such a way that type annotations can't influence the runtime behavior. This is unlike e.g. Haskell, where types can drive code generation. Happy to elaborate more if necessary.
This means that transpiling TypeScript to JavaScript consists merely of stripping the type annotations + transpiling some of the syntactic features that might not be supported by the target JS version.
The "Type Annotations" proposal (https://github.com/tc39/proposal-type-annotations), IIRC championed partly by the TS team, will allow type annotations with almost-TS-like-syntax in plain JavaScript, which will make the "stripping type annotations" step unnecessary. You would still use the TS tooling to actually type-check the code, though.
Which exact part of TS do you want to be built into browsers?