1 9eMyWLYOqU5aqBtVoFoi3Q
< < Articles

Why TypeScript?

09/02/2021

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.

TypeScript is built on JavaScript, which means that it can do everything that JavaScript does, and also adds the notion of Type.

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.

When we develop a web interface, we create files with code and a certain architecture organises those files. We can sometimes develop with TypeScript, sometimes with JavaScript, sometimes both. The libraries/frameworks that we use can compel us to use a given architecture and/or language. All those files and their architecture is not directly comprehensible by the browsers. Browsers understand JavaScript, they are not able to understand TypeScript (yet).

That means we must translate the files we are working on to produce a deliverable for the browsers : one or several JavaScript files. This traduction is called the transpilation step (traduction and compilation).

The execution happens when you are using a website : your browser downloads and interprets the JavaScript. This execution step is also called runtime. An error occurring at runtime will trigger a crash of your JavaScript application.

What is very important to understand here is that the deliverable being inevitably in JavaScript, TypeScript takes action before and during transpilation : it provides support during development. TypeScript will make it possible to detect errors during transpilation, donc before the code even reaches the browser, thus avoiding application crashes in production.

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
  • Most libraries export their types even if the code is in JavaScript, and if they don’t, the community will do it for them via DefinitelyTyped
  • Some libraries will even write documentations explaining how to use their tools using TypeScript (exemple with redux-toolkit)

2. Error detection

As just mentioned, TypeScript enables error detection at transpilation. In order to illustrate the difference between TypeScript and JavaScript and the power of this detection, here are two implementations of the same code in each language.

JavaScript version

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.

TypeScript version

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 ++

Let’s talk about the developer experience I mentioned in the introduction. The observation at ekino is that at the beginning some developers might be a bit reluctant when using TypeScript for the first time. It is a new language, one must learn, increase its skills and that takes a bit of time. Also, this language is much less permissive compared to JavaScript (which is extremely permissive). Looking back at the definition of typing : “compel the program to respect the definition of data”. We are indeed talking about additional constraints, developers must accommodate the requirements of types. They must write those types, which means less time for developing directly new functionalities, which might be stressful when deadlines approaches.

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.

The same exercise in JavaScript will really help understand the contribution of TypeScript here :

JavaScript version: (documentationJs)

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.

NB : The example here is simple, the log occurs directly when the JavaScript file is interpreted by the browser. Sometimes, like with the button on the previous example, the concerned code is not executed right away. If the data you are looking for is in a portion of the code that is executed when validating the 6th step of a fastidious form..good luck.

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. 😏