Not long ago, we lived through the battle of the JavaScript compilers. As a former C# developer, I was always on the TypeScript side. Still, many developers took the Babel.js side or even refused to use a compiler because they didn't want to deal with the additional complexity introduced by the tooling.
I knew the TS team was fully committed to collaborating with TC39. I never saw TypeScript as a threat, but, at the time, Microsoft was seen as the root of all evil, and many distrusted the TypeScript project.
Being able to use ES6 was an excellent reason to start using a compiler, but the killer feature became JSX. Thanks to the rise of React, compilers became mainstream, and TypeScript was winning a lot of momentum, but there was still a lot of distrust among javascript developers.
Later, we moved into the next phase of the compiler wars: static types vs. dynamic types. Developer picked their sides: flow type, Reason ML, Elm, TypeScript...
Fast forward to today. The battlefield is full of corpses, and one soldier still stands: TypeScript.
TypeScript has become the clear winner, but as adoption and project sizes grow, some teams worldwide are starting to experience a couple of issues: compiling times are too slow.
Compiling is divided into a few phases:
Parsing: Transform your code into an in-memory data structure called an abstract syntax tree (ATS).
Type-checking: Traverse the ATS in search of errors.
Emitting: Generate the output code.
The real issue here is the type-checking phase, but how can we make it faster? Some developers are already experimenting with languages like Rust. Writing a TypeScript type-checker in Rust should make it faster, but it will introduce the issue of having multiple TypeScript compilers: One TS compiler implemented in TypeScript, and another in Rust. It will be very hard to have both in sync all the time.
I will make my bet and say that I believe this is the way forward. I think we will one day run TypeScript natively in the browser, and this is just the first step. We will have a Rust (or another low-level language) implementation of the type-checker and then one of the emitter. A machine code emitter will someday replace the JavaScript emitter. Someone will implement a JIT version and we will use this in server-side engines first, but eventually, browsers will use it too. TypeScript will become JavaScript.
During the last few weeks, there was some big online debate about the friction generated by the fact that you cannot just run TS code directly. The issue here is not "TS the language"; is "TS the workflow". The proposed solution seems to be to use JSDoc version of TS (Types as JS comments), but I think people are forgetting that the compiler does more than type-checking (e.g. Use new ESX features or JSX). For me, using JSDoc is not the long-term solution; for me, the long-term solution is to have fast TS-native runtime. All the workflow-related friction will disappear once TypeScript becomes JavaScript.
I expect the TypeScript team to try to avoid getting involved in the non-TS implementations. They will continue to work on their TS implementation because the TS team understands that if they follow this path, a portion of the JS community will see them as a threat. If they just wait, the community will get it done for them without taking any risks. The first attempts are already in progress:
Top comments (0)