This article is translated from 7 Really Good Reasons Not to Use TypeScript by Michael Krasnov

A lot of people love TypeScript. It “solves” many of JS’s problems, is a “superset” of JS, and will make code easy to read. There are many reasons to use TypeScript, but I’ll give you seven reasons not to use TypeScript.

TypeScript risky

How can TypeScript add type definitions and check them at compile time be risky? IDE integration also warns you about type mismatches. But that’s the problem. TypeScript only checks for types at compile time, and only for available types. None of the network calls, system libraries, platform-specific apis, and untyped third-party libraries can communicate with TypeScript. When you get used to type checking without having to fully understand the code and platform, errors and bugs will show up.

With JS, you don’t have to make any assumptions about the type, and you can check the specific value of a variable to make sure it is what you expect. Or, if you don’t care about the type in this case, don’t do anything. In TS, you rely on the compiler to do this for you, but it can only check so much. You could combine the two approaches, but what’s the point? If you’re going to spend time writing definitions, and then you’re going to spend time writing code to make sure you detect types at runtime, why write types up front?

TypeScript is too messy

Another paradox: the language that is supposed to bring clarity and readability to the code base makes the code even more obscure. To illustrate what I mean, check out some examples I found in some popular open source libraries:

// TODO: dothis more elegantly ; ((currentReducer as unknown) as Reducer< NewState, NewActions >) = nextReducerCopy the code

This is from the Redux library, and the purpose of all four lines of code is to assign nextReducer to currentReducer.

// HACK: Since TypeScript inherits static properties too, we have to
// fight against TypeScript here so Subject can have a different static create signature
/**
 * Creates a new cold Observable by calling the Observable constructor
 * @static true
 * @owner Observable
 * @method create
 * @param {Function} subscribe? the subscriber function to be passed to the Observable constructor
 * @return{Observable} a new cold observable * @nocollapse * @deprecated use new Observable() instead */ static create: Function = <T>(subscribe? : (subscriber: Subscriber<T>) => TeardownLogic) => {return new Observable<T>(subscribe);
}
Copy the code

This example comes from the RxJS library. I don’t know about you, but if I have to use a tool, then I don’t think it’s a good tool.

TypeScript doesn’t solve the problem

TypeScript is said to solve JavaScript’s problems. But that’s not the case. Dynamic typing has never been a problem in JavaScript, but many other traps, such as NaN===NaN for false, semicolons for optional or optional, line breaks that change object definitions to scopes, using syntactic sugar instead of OOP, and so on, are indeed a problem. Instead of addressing these issues, TypeScript introduces another standard that further divides the JS community.

Even if the lack of type in the putative JS is a problem, TS cannot solve it. How can it be solved? Only Java, C, C#, and other compiled languages. They can safely ensure strong typing at compile time and run time. Translated languages cannot do this.

TypeScript is not a superset, but a subset

TypeScript can compile to JavaScript, but it cannot be a superset by definition. It limits what you can do with JavaScript and obscures its strengths while providing some psychological comfort. If you really want to be a great developer, don’t settle for superficial ease, but try to understand the true power and flexibility of JavaScript.

TypeScript is open source, but that’s about it

Many of the reasons to use TypeScript are because it is open source. Yes, the TS compiler is distributed under an MIT license. But it is still controlled by Microsoft, a monopoly, and its open-source advances are little more than marketing moves. Don’t confuse open source with democracy: Microsoft is still free to do whatever you want with TS, and you can only watch from the sidelines. On the other hand, JS is governed by an international committee and does not change anything without community approval.

But big companies use it…

I can’t believe anyone thinks this is a reason to use TypeScript. Big companies also use older versions of the code base to commit tax fraud and discriminate against women. Why is suddenly using TypeScript a good example?

But it has more features…

Not anymore. Indeed, when TS was first introduced in 2012, it had features like Class that were still not available in JS at the time. But JS has moved on a lot since then, and TS is struggling to keep up. If anything is missing from JS, you can use the Babel plug-in to do it.