When agility and speed of adaptation to business requirements have become the key to business success, JavaScript is strengthening its position, and with it, TypeScript flows on the rising tide. This programming language, released in 2012, is becoming more and more popular. Moreover, most programmers working with TypeScript would like to stick to it (2020 Stack Overflow Developer Survey ).
I spent the first few years in professional programming on projects using a technology stack based mainly on Java. However, it proved to be that knowledge of the general principles of server-side programming art is enough to pass the interview and start developing a project based on Node.js and TypeScript. It turned out that the change from "strongly typed language of corporate and large-scale business initiatives" (read: Java Enterprise Edition) to "statically typed language of agile and very flexible solutions for start-ups" (read: Node.js + TypeScript) it's not that hard at all.
After two years of working with TypeScript, I find a few key advantages of this language, which can be best illustrated by the example of individual stages of the Software Development Life Cycle. So why should you include TypeScript in your project's technology stack?
Let us conduct a simplified analysis of the implementation of new functionality in an existing application assuming that a business client already has an IT product based on JavaScript in the form of a browser application. Taking into account the Software Development Life Cycle: Planning -> Prototyping -> Implementation -> Testing -> Deployment -> Maintenance, let us consider at which stages TypeScript adds value.
Planning is usually done on a whiteboard and at a high level outlines the shape of new elements and their relationship to existing parts of the application, so there is not much to say about TypeScript here.
It is possible and desirable to use TypeScript in prototyping. We have a chance to plan how individual classes and functions will communicate. It is a good time to decide on the scope and shape of shared objects. Of course, types are not carved in stone. If there is a need to correct, extend or narrow the type later, we can always do so.
In the next step, during the implementation, all that remains is to write the code that will do the actual transformations that match the previously planned type signatures. TypeScript is brilliant in explaining the intentions of the code author. It embodies the creator's intentions as to how each piece of code should be used. Apart from the fact that it checks during the programming if all types match, it serves as project documentation.
During testing, it may paradoxically turn out that TypeScript makes it difficult to find the root cause of the error. There is a chance that the actual object that was processed during the application execution does not match the type we have assumed. However, these are sporadic cases. Most often, they happen at the interface between our application and external systems when we cannot ensure the quality of the response.
Implementation of the application in the production environment is the moment that finally verifies our assumptions about how the application will behave. Of course, at this point, the application users are running on the generated JavaScript code that is not type-safe. However, the fact that the production code was automatically derived from a safe TypeScript allows avoiding many unpleasant surprises.
At the maintenance stage, we go back to the code and apply minor or major corrections. And here, before we have to modify the code snippets, we try to understand them first. It's much easier with TS.
The clear abstraction layer that we build with TypeScript significantly reduces the effort needed to understand how a given piece of code should work and documents it. The fact is that it takes extra time to figure out the proper types, but it is spared to any subsequent programmer who tries to understand what the author meant.
TypeScript will undoubtedly accompany us in the coming years. I am lucky to be a part of a project where the value of solid typing is evident for all team members. There is a good chance that in some time, we will not even be able to imagine a large JavaScript project without TypeScript.
I wish this to all of you, myself and the end-users of our applications.
Jakub Springer
Node.js developer
