several reason why it's important to ship TS, not d.ts.: 1. TSC has an analysis budget, so it cannot unfold inferred types and generics down to many ideal instantiations properly (would blow up analysis time + space). Everything is bound by the speed of your type analysis and JS inference engine (same as in Go btw). Thus they have to use a good enough representation called d.ts to further compensate for its slow engine. example: xitter.cf/MarcJSchmidt/status/15… if the JS interpretation is slow to infer types and generics, it won't lay out the best function instantiation but one that is "good enough", stealing potential for JIT and AoT. 2. for every caller, if the function is not reduced and split up to the minimal concrete instantiations, you have lots of overhead on both, caller and callee side. When I was working on TypeRunner many years ago it was already pretty clear you cannot optimize the full call graph when you only have d.ts, you must have the full source-code to do the work that TSC did not do. TS types must become a program you execute for every single type inference/deduction/fn call, and not use an intermediate representation like d.ts. Knowing how often a concrete call was made to a function (in JIT and PGO) is also extremely powerful to move the 0.1% of calls to the slow path and lift the 99.9% to the fast one, which is only efficiently possible if you have lots of budget available in your analyzer engine.