Why you should use TypeScript in a project from scratch?
Mon, Aug 9, 2021 •12 min read
Category: TypeScript / Workflow / Frontend / Code-stories
What is TypeScript?
Advantages of introducing TypeScript right from the start
Avoiding JS errors
When we look at the list of the most common errors in projects that can be found, for example, on Rollbar or BetterProgramming, we immediately notice that virtually all of them refer to invalid objects that we pass or try to get to a field that doesn't exist.
TypeScript avoids this situation on several levels. First of all, the type system means that if we try to read a field that isn't in the object we receive while editing the code, we will be informed about it. The IDE will keep an eye on whether the fields and methods we use are available at all. Even if we ignore these errors at the stage of code editing, the TypeScript compiler will still inform us about them with a compilation error. So we can say that even if we try, the non-existent field's error is hard to miss. Secondly, when using TypeScript, we can enable disabling setting a variable or field to null or undefined explicitly or implicitly (with one flag in the configuration). Thanks to this, we minimize the risk of referring to non-existent objects.
You can read about the available type validation and null setting or writing more complex typing protections in the language documentation.
Static typing in the programming language enables tools such as Visual Studio Code to control our code more easily and efficiently, providing developers with additional options that are difficult to achieve with dynamic typing. One such option is code suggesting, which, thanks to static typing, works more precisely and relieves developers from the obligation to remember every field in a given object. Another possibility that is easier to implement and operate efficiently through static typing is any kind of static code analysis. Thanks to this, the tools we use give us an immediate answer to whether the code we write is correct and whether we're using the elements we wanted. This shortens the time between entering an error into the code and its detection.
In addition, static typing makes such a common activity as changing the name of a field, function, or class natural and works in most cases without any problems. That's because the IDE knows exactly where the name appearing in the code refers to the same element whose name is we're changing.
However, the situation begins to change dramatically as soon as we get to the point where we start referring to the already existing application elements and building complex structures. Thanks to static typing, syntax prompting works efficiently, and the developer doesn't have to stop every now and then to check or remember which fields contain the object. They will receive it in the function they write - after entering a full stop in the IDE, TypeScript will display a list of all available fields or methods.
All this allows the programmer to deliver business value from the beginning and use their time to expand the project instead of thinking about ways to protect code against errors resulting from the lack of static typing.
Clear contracts between modules
Thanks to tools such as TypeLITE, we can generate ready-made interfaces for TypeScript from C# classes by writing the API in C# and passing them to people responsible for integration with the API. Thanks to this, we avoid the problem of looking for the data we get from the API or the objects we have to send the API. In this case, we immediately get ready-made definitions that allow us to avoid the tedious search for such information in the documentation. We don't need to ask the API team about what should be sent.
In a situation where the API is written in NodeJS, the benefits of introducing TypeScript on both sides are more noticeable. In this case, we can directly create a set of interfaces shared between the API and the frontend. So, both the backend and the frontend will be working on exactly the same object structures they send.
Changing any field name won't be a problem either. That's because the tool doing it will know exactly where this object is used. Also, you won't have to synchronize independent definitions added separately in each project or modules.
However, application programming doesn't mean constantly writing prototypes, which will end up trashed in a moment. It's also about building code that will be developed over months and years - and during this time, it should be of the highest quality so as to avoid the time-consuming problem of introducing new or similar changes.
There are several elements to maintaining high-quality code.
First of all, it's the possibility of using commonly known solutions, such as design patterns. Since TypeScript introduces, among others, a system of classes and interfaces known from backend object-oriented languages, we can introduce proven backend solutions to our frontend code.
The second element that improves the quality of code written with TypeScript is the simplicity of refactoring. The refactoring process itself is something natural. But as long as we don't have clearly defined types and structures, changing the name of a field becomes extremely problematic - not only for the machine but even for the developer who would have to do it manually. By introducing a system of static typing and improved static code analysis already at the compilation stage, TypeScript allows programmers to modify the existing code much more confidently, without worrying that even a small correction of a typo could break something.
The last element is that there's no need to write any code that protects the project from absolutely every case where an object may be incorrectly structured or empty. By introducing TypeScript, we can eliminate the excess of instructions from our code, whose task would be only to protect against errors resulting from incorrectly passed objects. As a result, it's easier to keep order in the code, reducing the need to protect it against unexpected problems in every important function.
Compatible with JS
Understandable for backend developers
The fact that TypeScript in many respects resembles backend languages such as C# or Java means that we can relatively simply introduce it to programmers who have worked mainly with the backend so far (using the mentioned languages). They can now expand their competencies for a job with frontend development.
This similarity to backend object-oriented languages also allows us to introduce backend developers to the code review process or discuss code design with them. Thanks to this, we increase the number of people whose knowledge we can use in the project. This is a chance to introduce and disseminate ideas that have worked in other situations.
Introducing TypeScript at the beginning of the project gives us the opportunity to involve the entire team in the process of designing the code structure, regardless of whether we're talking frontend or backend. As a result, the solutions developed are more consistent and understandable for every technical project member.
We can sum up the benefits of introducing TypeScript to our project from the very beginning in three points:
higher code quality,
pleasure from working on the project.
This allows developers to focus on delivering high-quality business value right away. And because static typing simplifies the refactoring process and facilitates the implementation of well-known patterns, the quality of code the team delivers is easier to maintain at a high level for a longer period. This is even more important in the project's initial phases; when changes appear frequently, ideas and needs change dynamically. The process of changes in data structures is continuous. In such a case, efficient control over types and ease of refactoring mean that the maintenance and development of the code don't give the team any headaches and minimizes the risk of increasing the time needed to introduce new functionalities.