Deno problems with TypeScript
The unfavorable situations that the Deno team is currently experiencing while using TypeScript for its internal code are:
- TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process
- The Typescript structure that they’re using in the source files that create the actual Deno executable and the user-facing APIs is creating runtime performance problems
- TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations https://github.com/denoland/deno/issues/4748
- The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files
- They’re maintaining two TS compiler hosts: one for the internal Deno code and another other for external user code even though both have a similar goal
Removing TypeScript in internal Deno code
It’s worth mentioning that Deno will stop using TypeScript only for the internal Deno code: the Deno user code will still be in TypeScript and thus type checked.
The safety of type checking during development does have its cost at compilation time. It’s not without reason that the TypeScript project has an extensive document on how to address and improve compilation time. One of the most interesting approaches is to use Project References, that allows developers to break apart a big TypeScript piece of code into smaller pieces.
Read more about why Deno will stop using TypeScript