Here is why you might NOT want to use TypeScript — Part 1: Alternatives
Recently I read a post called “Why would you NOT use TypeScript?”. I found that post a bit biased, so I decided to play advocatus diaboli…
Disclaimer: I am working as a consultant and trainer for modern web development in the enterprise. For most of those projects I unconditionally recommend to use TypeScript. But there are also many reasons not to use TypeScript in some projects.
When starting a new project or reviewing an existing project, I evaluate on a case-by-case basis:
- Is a static type checker for JavaScript worth the effort?
- Is TypeScript the right tool for static type checking or should we consider an alternative?
I see three broad reasons not to use TypeScript in a project:
- This first post is about alternatives to TypeScript which might be a better fit for the project.
In two separate posts I write about:
- TypeScript adds an overhead to the project, which might not worth it.
- TypeScript is not JavaScript, which might have negative implications.
Alternative to TypeScript: Babel as a Transpiler
Update 2018–12–29: Babel 7 was released with TypeScript support. This makes it possible to write TypeScript code and transpile that code with Babel to code that runs in the browser. Babel does not do any type checking, it just strips away any elements of TypeScript. But if you want type-safety you then can run the TypeScript compiler separately in “check-only” mode in parallel to the Babel compiler.
create-react-app adopted this approach with their official support of TypeScript in v2.1
A drawback of this approach is to make your project dependent on both Babel (with its transitive dependencies) and on Typescript. Time will tell if those two projects will evolve in sync so that transpiling and type-checking with different tools will not lead to problems …
According to Microsoft: “Using the TypeScript compiler is still the preferred way to build TypeScript.”
An advantage of the approach is that you can use the Babel ecosystem/plugins as long as it is not related with syntax features that the TypeScript compiler does not support.
The most prominent reason not to use TypeScript is the fact that TypeScript is a static type checker and a transpiler at the same time. As a consequence you can’t use Babel as a transpiler.
The Babel ecosystem is very rich, and there are many useful Babel plugins. When using TypeScript you can’t use that ecosystem.
Example Babel plugins that go beyond language features:
- idx: Transpile the
idxfunction to efficient code - styled-jsx: Transpile scoped CSS from JSX components
- react-intl: Extract text for translation
Babel also offers the possibility to use experimental features of JavaScript, that are not yet standardised. A cool feature for instance is do expressions. TypeScript is a bit more conservative and only implements features of JavaScript that have reached at least stage-3 of the standardisation process.
Technically it is possible to use more than one transpiler: Pipelining the output of the TypeScript compiler through Babel. But this has performance implications and leads to even more convoluted tooling pipelines.
In the future it might be possible to use Babel with TypeScript: Babel 7 can transpile TypeScript to JavaScript. Then you could use the TypeScript compiler just as a type checker. See this repository for an example.
Alternatives to TypeScript: Static Type Checking
Currently TypeScript is without doubt the most prominent solution for providing static types to JavaScript. There is a big community and ecosystem and very cool tooling around TypeScript. The adoption appears to be sky-rocketing in recent years.
However there are alternatives to TypeScript, providing similar advantages:
- Flow is already very popular, especially in the React ecosystem
- ReasonML/BuckleScript has also received a lot attention in recent months
Lesser known projects are: Elm, PureScript, Haxe …
The advantage of Flow over TypeScript is that it is just a type-checker. Therefore it currently integrates better with projects that are using Babel as a transpiler.
ReasonML has impressively short build times. It’s considerably faster than TypeScript, which is a definite usability advantage.
- Dr. Axel Rauschmayer, JavaScript vs. TypeScript vs. ReasonMLWith Flow you’ll have much higher type coverage much faster than with TypeScript.
- Adopting Flow & TypeScript / discussed on ReditFlow is more efficient than TypeScript by requiring less type annotations.
- To type or not to type: quantifying detectable bugs in JavaScript
We have to remember in frontend development everything is changing at a unhealthy pace.
TypeScript has been around since 2012. In its first years, TypeScript was only used in the “small” ecosystem of .NET web applications (at least that was my perception). I think it was the adoption by Angular that drove TypeScript to its current success in a wider ecosystem.
However the next big hype after Angular might promote another flavor of typed JavaScript (we might already see this with React/Flow)…
