For starters, v8 predates (public knowledge of) TypeScript by several years, TypeScript isn’t from Google, TypeScript is far from an industry standard, and Google has its own language trying to fill a similar niche (Dart). And then there’s the problem that nobody deploys TypeScript to websites, it’s designed to be compiled to JavaScript and that’s what everyone does. But let’s assume none of this matters.

I don’t believe that there are any performance gains to be had. Precisely because it is interoperable with JavaScript, TypeScript’s type system provides virtually no hard guarantees. Sure, it allows workable autocomplete in most circumstances, but it does not guarantee that the types are all 100% correct. With type assertions (<Type> something), you can smuggle type errors past the type checker, and it’s not even a runtime error. TypeScript code can and does call into JavaScript code, which might break any guarantees in arbitrary ways. So V8 can’t rely on anything the TypeScript types assert.

JIT compilers can already figure out all information they need for optimization with runtime instrumentation. TypeScript can’t statically eliminate the need for those checks, so it provides no extra value.

Maybe the types could give the baseline compiler an initial guess for speculative optimizations (which would be overridden by runtime profiling data in later stages), but:

1. That there is a benefit at all is complete speculation at this stage.
2. Type checking and inference takes time, and time is precious for baseline execution. Browsers want to start executing scripts as soon as possible.
3. It would have to be worth the extra complexity and implementation effort.
4. see the first paragraph.