Here is why you might NOT want to use TypeScript — Part 2: TypeScript adds Overhead

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?

In this second post about the topic, I look into the overhead TypeScript adds to a project.
In the first post I wrote about alternatives to TypeScript.
In a third post I wrap up with some negative implications of TypeScript not being JavaScript.

TypeScript is an Overhead: Introducing a static type system

The main value of TypeScript today is adding a static type system at compile time. Depending on your project as well as the background and mindset of the team, the value of a static type system and thus the value of TypeScript might be questionable.

The value of a static type system is not undisputed. There are many claims that a static type system doe not prevent bugs or increase the quality of a project. The disadvantages of a static type system are about loosing the flexibility and elegance of a dynamically typed language and the additional complexity, noise and effort introduced by the type system.

Modeling generic code with a static type system can quickly become complicated , noisy and difficult to understand. Here is an example from this GitHub thread:

I think that JavaScript’s loose typing is one of its best features and that type checking is way overrated. TypeScript adds sweetness, but at a price. It is not a price I am willing to pay.
- Douglas Crockford

In many smaller-scale use cases, introducing a type system may result in more overhead than productivity gain.
- Vue.js Developers Guide

Static typing is an additional layer of complexity. You are basically writing the code again, on a different level.
- Dr. Axel Rauschmayer, JavaScript vs. TypeScript vs. ReasonML

TypeScript comes with a substantial cost, and it wouldn’t be wise to ignore it.
- Eric Elliot, You might not need TypeScript (or Static Types)

Static types give you a false sense of security. Type correctness does not guarantee program correctness.
- Eric Elliot, The Shocking Secret About Static Types

Here is a list of studies that research the topic of Static vs. Dynamic languages.

TypeScript is an Overhead: Implying a build step

TypeScript is a compiled language, this implies you need a build step for compilation.

There are many projects out there where a build step does not makes sense. Especially regarding the fact, that the state-of-the-art build tooling in the JavaScript ecosystem is re-invented every year.

Perhaps you don’t want to set up an entire build system for some small abstractions you could feasibly do without.
- Replacing jQuery With Vue.js: No Build Step Necessary

If your project does not need a build step, then you can’t use TypeScript.

The “real frontend engineers” among the audience will claim that projects without build step are just no “real projects”.

I see in most enterprises many small web pages providing some functionality or information for different end-users (process monitors, reports, simple process controls of data input …). The strength of the traditional web platform is that it is very easy to build a small html site, which is enhanced with JavaScript. This can provide immense value at a very low cost.

Also I think the pendulum will swing back from the current SPA-hype to server-rendered and “client-side enhanced” pages for many use cases line-of-business applications.

In these scenarios the model of adding some simple <script src="..."> to small pages is very productive. Optimising steps are often not needed for such in-house line-of-business applications.

TypeScript is an Overhead: Complicating existing build toolchains

Starting with the TypeScript compiler is not difficult: tsc --watch

But if you already have a build pipeline (maybe still based on grunt or gulp then you are probably doing some other processing steps that have to play well with the TypeScript compiler. i.e. template preprocessing/inlining, minification, source map generation … understanding and maintaining modern frontend build toolchains is a lot of work and a constantly moving target. Sometimes it is just not worth the effort to introduce yet another tool, sometimes it is really not feasible to do it.

Tools like the angular-cli or create-react-app help tremendously to reduce the effort to create/maintain a modern frontend build, but for some legacy projects these are just not an option.

Also there have been repeated cases where a new versions of TypeScript breaks existing code. Prominent examples that come to my mind are:

• New errors with RxJS on 2.4.1
• @angular/core is not compatible with Typescript 2.4.1

With TypeScript your build toolchain gets more complicated. This might be a cost that you are not willing to pay.

TypeScript adds an overhead on a conceptual level by introducing types and on a technical level by requiring a build step. For some projects this overhead is just not worth it.