Before going to the technical core of this posts series, we said in the summary that by default TypeScript:
- only partially enforces typing
- does not handle nullability
- retains some JavaScript's dynamic typing
We will explain these 3 problems and their solution in the next parts, but first, why is it important to solve them? Developers coming from Java, C# or Rust may not need to be convinced, and could skip this introduction.
We will cover:
- TypeScript true promise
- Reliability: bugs reduction
- Productivity: easier and faster debug
- Productivity: better autocompletion
- Productivity: less tests to write
- Scalability: safer refactoring
- Design: better and simpler code
- Put into perspective
TypeScript true promise
Having a code as correct as possible is not about being picky or about wanting a pretty code. It has very important and concrete consequences for a company.
Imagine one finds a magic box which can guess the lottery numbers. They just press the obvious big button on it and it guesses 3 out of 6 lottery numbers.
Now they turn the box upside down and press the little and barely visible secret button with "strict" written on it. Now the box guesses all the 6 lottery numbers.
Using TypeScript with its default behavior is basically the same as using the magic box without the secret button.
So answering why enforcing static, strong and complete typing is important is the same as answering why TypeScript is important. Once it is clear, it is just common sense to use TypeScript to its maximum potential.
Reliability: bugs reduction
It is the most obvious benefit:
- JavaScript: 0% code verified, 100% risk of bugs
- TypeScript default mode: ~60% code verified, 40% risk of bugs
- TypeScript strictly typed: ~100% code verified, 0% risk of bugs
To be clear:
- ~60% is a rough estimate from my experience
- 0% risk of bugs = 0% risk of bugs which are handled by strong and static types, but of course there are other types of bugs which are still possible
Put in a real world context, where front-end teams are often new small teams, the maintenance costs are very important. If a team is made up of only 3 people, and 2 of them use all of their time to fix bugs, it means there is only one person left to add new product features.
Productivity: easier and faster debug
To check the code, TypeScript introduces a compilation step, like in other typed languages like Java, C# or Rust. And in TypeScript, compilation is happening in "watch" mode, while one is coding.
It is a totally different experience when it comes to debugging. Let us take a very basic example:
document.querySelector('#missing-id').textContent = "The Matrix";
With TypeScript strictly typed, the error is shown directly and immediately as one is coding (via the editor or via the compilation logs). There may even be a suggestion about how to fix the issue. It takes a few seconds.
Now going back to the raw JavaScript experience: everything seems OK in the editor. One has to launch a development server, go in the browser and open the console. Yet it is not enough: the console logs may be totally OK at this point. One has to reproduce the steps to trigger the scenario where the faulty code is called.
We are now talking about minutes of debugging, which can extend to hours.
And now imagine the faulty code is called in a scenario which does not happen often or which happens only under specific conditions. So it goes totally unnoticed while developing in local environment, and a bug is pushed to production.
Productivity: better autocompletion
If TypeScript is able to check all the code because everything is correctly typed, it also means the editor can help with autocompletion everywhere.
Once one goes back to any, the editor becomes blind, and cannot assist the developer anymore.
Interesting fact: if editor autocompletion in JavaScript is far better than some years ago, it is because it is now handled by TypeScript, even for pure JavaScript files!
So in some sense, like it or not, everyone is doing TypeScript today, and it is just a waste to not go for its full potential.
Productivity: less tests to write
If one is talking about testing strategies, but TypeScript is not in a strictly typed configuration, priorities may have to be reconsidered.
A very common and indicative case are unit tests checking unexpected undefined values: with TypeScript strictly typed, it cannot happen at all, so it does not need to be tested!
Everyone who has already written tests in a front-end project knows how time consuming it is. Also, the more tests = the more time the continuous integration tools (like GitHub Actions or else) take. And as these tools are not free, the more it costs to the company.
Scalability: safer refactoring
For the same reasons as for bugs, refactoring is a lot easier when in TypeScript strictly typed, because if one breaks something while refactoring, compilation will see it and notify it right away.
The accumulation of technical debt being one of the other major problems of most projects, being able to easily evolve is essential.
Design: better and simpler code
This benefit is rarely evoked, but I realized with experience that TypeScript is also a good indicator when designing code.
Too difficult to express the type of a variable? One may have chosen the wrong data structure, or a too nested one which would be easier to work with if it was flattened.
Too difficult to express the signature of a function? It may do too much things and not respect the single responsibility principle, or it may try to abstract too much.
Put into perspective
While the options names like "strict", which we will discuss in the next parts, may suggest it is an additional effort to do, it is not: enabling all the strict options we will discuss is just putting JavaScript at an equivalent level than the basic and default mode of the other typed languages like Java, C# or Rust.
One could say that it is TypeScript default mode which is a "loose" mode, while "strict" mode is just the normal mode if one wants to use strong and static types, which is what TypeScript is for in the first place.
Next part
In the next part of this posts series, we will explain how to configure a project to guarantee strict typing, and especially when it is important to do it.
You want to contact me? Instructions are available in the summary.
Top comments (0)