There's AssemblyScript, which is designed to be Typescript-esque, and compiles to webassembly, but apart from that, there's not much. The thing is that there's not much value in a Typescript runtime. The semantics of Typescript are fundamentally the semantics of Javascript, but with labels attached to each variable giving a rough hint as to what the type might be. For static analysis, that's really useful - rough hints are mostly good enough for human things like editor hints and typechecking that are allowed to be incorrect - but when it comes to executing the code, the type hints don't actually have that much value. It's very easy for them to be incorrect ("A as B" is a valid Typescript construct that just asserts that a variable is a type without needing to check that it's actually the case), and so the runtime engine can only ever use them as a hint. But with the JIT engines that must runtimes use, the interpreter already has a pretty good idea what the type is going to be, because it's already executed the code and inspected the runtime variable. So you don't get a huge amount of practical value by using the type hints.

And if the type hints aren't useful for the runtime, then there's no real reason to enforce that they be present. A Typescript runtime that ignores types is just a Javascript runtime with a more pedantic syntax, and if you're going to that effort, you may as well support both.

Not now but there is work going on in the JS standardisation process that will mean valid typescript is interpreted as valid JavaScript. (Basically run it and ignore the type annotations)