mobileRumblefishLogo
Menu
desktopRumblefishLogo
Services
Products
Case studies
Careers
Resources
About us
Why you should use TypeScript in a project from scratch?

Why you should use TypeScript in a project from scratch?

Mon, Aug 9, 202112 min read

Category: Code Stories / Software development

What is TypeScript?

TypeScript is a JavaScript superset developed under the wing of Microsoft. This means that TypeScript doesn't replace the JavaScript syntax but extends it with additional functionalities or provides alternatives to encapsulate the originally available elements. What TypeScript adds (and what its name implies) is the static typing system.

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.

Tool support

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.

Developer performance

The advantages mentioned in the previous points lead us to the next one, which is the time needed to apply changes to the project. Starting a project with TypeScript may initially feel like spending more time writing additional code than the JavaScript code. 

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. 

Besides, by eliminating errors that are common in JavaScript and related to the passed objects that don't necessarily match what we expected already at the compilation stage, the developer avoids spending excess time on writing all kinds of security against such situations - because the language already gives it. And since such errors are caught immediately and automatically, you can avoid a large part of the work associated with the tedious search for the cause of an error where an object doesn't contain the field that we expected, or we try to refer to a value that doesn't exist.

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

Introducing TypeScript allows you to introduce clear contracts between modules and between the frontend and the API from the very beginning. By choosing TypeScript over JavaScript, we simplify the team's work on individual application modules. Having specific interfaces to deal with, neither party will have any doubts about what data it will get from another part of the application or what object the function someone else wrote expects.

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.

Code quality

Due to the loose approach to the data we transmit and on which we operate, JavaScript certainly allows you to create a prototype of the functionality faster than TypeScript code. 

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

Since TypeScript is a JavaScript superset, it doesn't break compatibility with the existing JavaScript code. The result is that if we decide to write code using TypeScript, we don't lose access to libraries prepared for JavaScript, and we gain all the advantages of TypeScript. 

So, the decision to choose TypeScript doesn't close the doors to using the code that wasn't created with this language in mind. Thanks to this, we eliminate the risk related to the incompatibility of the library with the language that we're using. We take advantage of static typing while maintaining full access to a rich library of ready-made solutions that were developed for JavaScript.

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.

Summary

We can sum up the benefits of introducing TypeScript to our project from the very beginning in three points:

  • fewer errors,

  • higher code quality,

  • pleasure from working on the project.

TypeScript takes some of the work related to protecting against typical JavaScript errors from the team while making the tools used by developers better partners at work. It also makes writing code easier, giving better suggestions and relieving developers of the responsibility to remember or check what data are communicated to them or forward in a given context.

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.

Rafał Lizoń
Rafał Lizoń

Full Stack Developer at Rumble Fish

Categories
Follow Us
AnimatedLogoTextImageAnimatedLogoFishesImage
RUMBLEFISH POLAND SP Z O.O.Filipa Eisenberga 11/3 31-523 Kraków, Polska
NIP: 6772425725REGON: 368368380KRS: 0000696628
P: +48 601 265 364E: hello@rumblefish.dev
Copyright © 2024 Rumblefish