Everyone loves TypeScript. It “solves” many problems JS has, it is a “superset” of JS, it will make your code less error-prone and pleasant to read. There are a lot of good reasons to use TypeScript, but I am going to give you 7 really good reasons not to.
It is risky
Wow. How can it be risky, if TypeScript adds type definitions and checks them at compile time? As well as IDE integration will warn you about any type mismatches? Exactly because of that. TypeScript will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript. As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.
With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be. Or, if you do not care about its type in this particular case, you do not. In TS, you rely on the compiler to do it for you, but it can only check so much. You can combine the two ways, but what is the point then? If you will spend time writing definitions and then spend time writing code to ensure these definitions are maintained during runtime, why have them in the first place?
It is messy
Another paradox: the language that was supposed to bring clarity and readability to the codebase obscures it instead. To show you what I mean, check out some of these examples I found in popular open-source libraries:
Everyone loves TypeScript. It “solves” many problems JS has, it is a “superset” of JS, it will make your code less error-prone and pleasant to read. There are a lot of good reasons to use TypeScript, but I am going to give you 7 really good reasons not to.
It is risky Wow. How can it be risky, if TypeScript adds type definitions and checks them at compile time? As well as IDE integration will warn you about any type mismatches? Exactly because of that. TypeScript will only check types at compile time and only types that are available. Any network calls, system libraries, platform-specific APIs and non-typed third-party libraries have no way of communicating with TypeScript. As you get used to having your types checked and not having to fully understand the code and the platform, errors and bugs will manifest themselves.
With JS, you make no assumptions about types, and you check the concrete value of the variable to make sure it is what you expect it to be. Or, if you do not care about its type in this particular case, you do not. In TS, you rely on the compiler to do it for you, but it can only check so much. You can combine the two ways, but what is the point then? If you will spend time writing definitions and then spend time writing code to ensure these definitions are maintained during runtime, why have them in the first place?
It is messy Another paradox: the language that was supposed to bring clarity and readability to the codebase obscures it instead. To show you what I mean, check out some of these examples I found in popular open-source libraries: