The benefits and drawbacks of using TypeScript over JavaScript
JavaScript is a popular programming language that is widely used for web development, mobile development, and more. It is a dynamic, interpreted language that is easy to learn and has a large, active community of developers.
TypeScript is a superset of JavaScript that adds optional static typing and other features to the language. It was developed by Microsoft and is gaining popularity among developers for its ability to improve code quality and reduce errors.
So, let’s dig into the 5 million dollar question. Is it even worth using TypeScript at all?
Drawbacks:
Not using it at all
I wanted to start with the biggest drawback. But, this drawback is related to how people are using it rather than the language itself. I’m sure you have or will see codebases that have tons of tons of any keyword sprinkled around to avoid TypeScript. Doing this might seem unharmful for some, but the thing is while doing this, you are disabling the vanilla JavaScript intelli-sense and problem checkers for that declaration as well.
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.
Signal-to-noise ratio
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.
TypeScript is a superset of JavaScript, which means that you can write vanilla JavaScript code within TypeScript without any additional changes. This means that the signal-to-noise ratio of TypeScript can be the same as that of JavaScript by default.
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.
So, with these kinds of rules, the signal-to-noise ratio grows really fast compared to vanilla JavaScript. You are writing more and more to achieve the same thing.
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.
Benefits:
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.
If you have been programming for at least six months, you likely have a good understanding of the code execution path. However, if you are new to programming, the concept of code execution path may be difficult to grasp. In this case, using TypeScript while writing JavaScript can be helpful, as TypeScript will alert you to any problems with the code execution order in each block of code. This can be a valuable learning tool, even if you are working with vanilla JavaScript, as it helps you understand the code execution path more fully.
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
In large JavaScript repositories, refactoring is a literal hell. Because there is nothing to rely on to find what is broken after changing some variable or a function or anything besides the good ol’ Cmd+F or CTRL+F. It gets frustrating over time and you often end up breaking things that working before the refactoring.
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.
Browser compatibility
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.
In conclusion, TypeScript offers both benefits and drawbacks compared to JavaScript. On one hand, it adds optional static typing and other features that can improve code quality and reduce errors. It can also be a useful learning tool for understanding the code execution path. However, it can also add complexity to the development process and increase the signal-to-noise ratio, requiring more code to be written to achieve the same results as in vanilla JavaScript.
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.
