> But maybe one day browsers will have native TS support?
This may already be a thing; node has native TS support by just ignoring or stripping types from the code, TS feature that can't be easily stripped (iirc namespaces, enums) are deprecated and discouraged nowadays.
TS is not actually that special in terms of running it. TS types are for type checking which isn't done at runtime, running TS is just running the JS parts of the code as-is.
For non-browser runtimes, react native is actually working on an AOT TS/Flow engine. But they ship a bytecode binary rather than what I'm proposing, although what I'm proposing might also be infeasible.
Porffor is doing that, JS -> WASM (an an IR) -> C -> Native
For TypeScript it uses the types as hints to the compiler, for example it has int types that alias number.
Very early still, but very cool.
https://porffor.dev/
Compiled to what, wasm?
I wasn't thinking about browser runtimes. But maybe one day browsers will have native TS support?
> But maybe one day browsers will have native TS support?
This may already be a thing; node has native TS support by just ignoring or stripping types from the code, TS feature that can't be easily stripped (iirc namespaces, enums) are deprecated and discouraged nowadays.
TS is not actually that special in terms of running it. TS types are for type checking which isn't done at runtime, running TS is just running the JS parts of the code as-is.
Well we'd need browsers to natively support type stripping.
For non-browser runtimes, react native is actually working on an AOT TS/Flow engine. But they ship a bytecode binary rather than what I'm proposing, although what I'm proposing might also be infeasible.