5 reasons why Deno will stop using TypeScript

A document surfaced today pointing that Deno will stop using TypeScript in its internal code, citing several problems with the current environment. Issues mentioned involve TypeScript compiling times, structuring and code organization, among others. Moving forward, Deno will use pure JavaScript for its internal code.

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

The Deno team aims to remove all build-time TS type checking and bundling for internal Deno code. They’re looking forward to move all the runtime code into a single JavaScript file. However, they’ll still use a companion d.ts file to keep the type definitions and documentation.

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.

While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. It has flaws like any other language. One of the most important ones is its slow compilation time. While small projects might not see a huge spike in compilation time when switching from pure JavaScript to TypeScript, it will be noticeable in large projects like a complex React app. Given the large size of its runtime, it’s not surprising that Deno will stop using TypeScript.

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

The complete discussion about the decision to drop TypeScript from the internal Deno code and use JavaScript instead can be found in this document, where Ryan Dahl and collaborators discuss the problem, its solution, and how it’s going to be implemented.