It's a real example of "you can solve just about anything with a billion dollars" though :)
I'd prefer JavaScript kept evolving (think "strict", but "stricter", "stricter still", ...) to a simpler and easier to compile/JIT language.
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 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.
It'd need a ton of buy-in from the whole community and all VM implementors to have a chance at pencilling out in any reasonable time span. Not saying I'm against it, just noting.
>runtime-level APIs
like the Document APIs?
Yeah, the DOM in the browser, node APIs in nodejs, etc.
> especially if it was faster
Well, that's the thing. Initially it'll be slower, 'cause the code you call, and that calls you will be mostly unsound.
Unless you can run the sound code without the soundness checks at boundaries, at which point it becomes harder to reason about, and you'll be tempted to add some additional runtime checks to your code that the type system should catch.
This is / was ASM.js, a limited subset of JS without all the dynamic behaviour which allowed the interpreter to skip a lot of checks and assumptions. This was deprecated in favor of WASM - basically communicating that if you need the strictness or performance, use a different language.
As for JS strictness, eslint / biome with all the rules engaged will also make it strict.