Cet article est également disponible en français.
I would like to start this article by explaining why I chose the title “Why typescript” over “Typescript is better”.
This article is not only meant for developers, it is meant for anyone participating in a digital project, from the project manager to the client paying for the website. Each of those people will have its own experience regarding a new language and its own expectations (but they are of course often shared). Some will focus on improving developer experience, others on the delivery of a website with less critical bugs as possible. Some will also think about recruitment issues for hiring developers with TypeScript experience. We must also take under consideration that there is a subjective aspect to developments, developers do not all like the same things. Thus, I can’t say : “TypeScript is better”, because it just might not be better for you and/or your project. What I can do is explain why TypeScript is better for me, why more and more developers are conquered by it and why more and more libraries are at least exposing types for their object if not completely migrate to TypeScript. I hope this article will help you make a more informed choice regarding your project.
1. Let’s start with the beginning, what is TypeScript ?
TypeScript is a typed programming language created by Microsoft in October 2012 with the version 0.8. The langage really started being popular with the release of the version 2.0 in september 2016.
What does typing mean ? It means compelling a program to respect a definition of data for a variable otherwise it will trigger errors during compilation or execution. Let’s top a few seconds to explain what compilation and execution mean.
Today (november 2020), the 4.0 version of TypeScript was just released and the developer community has grown :
- TypeScript is the language used by Angular
- Some libraries will even write documentations explaining how to use their tools using TypeScript (exemple with redux-toolkit)
2. Error detection
The aim is to call the triggerError function when clicking on the button. The triggerError function wants to access the field cat from an object that must be passed as a parameter. I voluntarily omitted to pass this parameter to trigger an error. You can see that this mistake is not detected while writing the code, or during transpilation. It is detected at runtime, once the code has eached the browser and once the user has clicked the button, triggering the execution of the incorrect code. In conclusion, the error occurred during the test phase, or worse… in production.
As you can see, the error was detected directly during code writing (thanks to the IDEs that we use such as VSCode or Webstorm) and during transpilation. It is impossible for this incorrect code to end up in the browsers because it is simply impossible to create the deliverable for the browsers. The developer realises his mistake while writing his code, the diagnostic is immediate and easy, TypeScript helps him.
It is important here to clarify that using TypeScript in your project will not prevent any error at runtime : zero mistakes is impossible. TypeScript is a tool, and like any tool it can be used properly or not, and like any tool it can not remedy all issues.
However, as this example just illustrated, TypeScript can considerably reduce crashes in production. That means more confidence for developing new functionalities, or evolutions of existing ones, for the developers as well as the project manager as well as anyone working on the project.
Writing types requires rigour from developers because they will be the frame of the code and will be used on the long term (which helps maintaining the website). An incorrect type could lead to many issues because it will be used by all developers.
3. Developer experience ++
However, after a few months, those exact same developers that were a bit struggling at the beginning will often say : I can’t go without TypeScript anymore. TypeScript’s strength is not felt at the beginning of a project, but in the long-term.
NB : the language evolves very quickly and the developer community is getting bigger and bigger. Microsoft releases new versions often which make the language easier to learn as well as providing features that are more and more powerful.
Once developers are at ease with the language, they have a better understanding of the code and of the libraries that we use.
But the most significant and revolutionary aspect with TypeScript for front-end developers, is auto-completion. (Right now, back-end developers are laughing because that is something that they have been using forever). But for front-end developers, auto-completion is THE feature that makes you addicted to TypeScript. TypeScript acts as a live documentation and enables developer tools (IDE) to offer a reliable auto-completion.
Below two videos will help illustrate what I am saying (starting with TypeScript this time) :
TypeScript version: (documentationTs)
The aim is simply to display some information that is passed to our React component using props : the name, last name and color of a cat. As you can see on the video, the prop’s structure is described by a type. The developer knows exactly which properties he must access to get his information. Moreover, the auto-completion guides him into selecting the correct properties and avoids typing errors.
When the developer reads the code from the React component, he knows...nothing. He only knows that there is a props object, but he does not know its structure. So he must add a log, transpile his code, deploy his version on the browser and trigger the code execution to see what this object props is.
Once the developer knows the object structure, he can start implementing the feature. But even then, without auto-completion and error detection, he might make a typing mistake for example and lose time.
4. TypeScript provides a frame
This last paragraph is less factual and is more a feedback after using TypeScript for 3 years. Types can be compelling, but they provide structure to our development. Developers have to be more rigorous. It is of course possible to be rigorous without TypeScript, but with TypeScript, it is difficult not to be (if you use it properly of course).
Developing with TypeScript make me think differently and acquire some reflexes :
- Spend more time thinking ahead of code writing and architecting
- Master and know the data structure of my application. TypeScript allows me to create my own data model which can be completely unrelated to the external services I use. My code is more agnostic.
- Think re-usable
- Think about the next developer that will use my code : Is my type explicit enough ? Is it correct ? Is it logical that my function can return 5 different types ? Wouldn’t it be easier, more readable, more safe to always return the same type ? Which would lead to simplifying the function and maybe refactor the architecture.
All these things are doable without TypeScript, but using this language “opened my chakra” and triggered and/or accelerated this process.
I hope this article helped you understand developers’ interest in TypeScript and the different concepts it brings. I would not say that “TypeScript changed my life”, but it damn improved my developer experience and the quality of the code I produce, thus the applications I deliver as well as for other developers.
NB : But still, TypeScript is really better. 😏