So, let’s dig into the 5 million dollar question. Is it even worth using TypeScript at all?
Not using it at all
Solutions for this are simple; giving them hell in code reviews. And, trying to explain to them why we are using TypeScript in the first place.
I should start with a brief explanation of what is signal-to-noise ratio:
You can refer
signal as meaningful information. In other words, it is what you intend to achieve.
And, you can refer to noise as unnecessary, irrelevant information. In other words, it is information that does not contribute to the meaning or purpose of the code and can make it harder to understand. Noise can include things like unnecessary comments, complex syntax, or unnecessary rules or restrictions. It can distract from the useful, meaningful information in the code and make it harder to read and understand.
However, this is not often the case because, first, it defeats the purpose of using TypeScript in the first place, and second, codebases often enforce rules against this, such as explicitly declaring types, mandatory access identifiers for classes, mandatory return types, and such.
Pretty much non-existent in the runtime
TypeScript’s static typing system means that types are checked at the code level, rather than at runtime. This means that type errors are caught during the development process, rather than when the code is being executed.
The effectiveness of TypeScript depends on how accurately the type declarations match the behavior of the code at runtime. Failing to do this, might result in additional problems you need to deal with.
Gives a good idea about the code execution path
The code execution path refers to the order in which code is executed by the computer. The code execution path determines the sequence of steps that the computer follows in order to carry out the tasks specified in the code. Understanding the code execution path is important for writing efficient and error-free code.
Also, grasping the code execution path will result in writing more robust code, and writing robust code often goes hand in hand with writing testable code.
Makes refactoring a breeze
With TypeScript, with the condition of types written correctly, refactoring feels somewhat safer. You don’t worry about breaking things as TypeScript got your back in case of a type conflict.
With TypeScript, god forbid if we need to target IE11 for some reason, it is really easy to do it. You can write ES2022 and TypeScript can convert it to ES3 or some other specification-compliant code when building it. With exceptions though, TypeScript cannot convert everything.
Following changes and Intellisense
Thanks to TypeScript, we can write interfaces and types for objects, arrays, and functions. Firstly this makes the effort of following changes in an object or array very easy. Second, with IntelliSense, we can correctly refer to the property inside an object without doubting or having the need of correcting the property name because of writing it wrong the first time.
Ultimately, whether or not to use TypeScript depends on the specific needs and goals of your project, as well as the preferences and skills of your development team.