What’s with TypeScript?

It was not long ago when I started working here at Light-it. Back then, we worked solely with PHP in Laravel and JavaScript in React. One of my first doings was convincing my team TypeScript was the way to go instead of JavaScript, and now we have proudly added TypeScript to the list of programming languages we develop in.

But why did I do that?

First of all, since I came from statically typed languages such as C#, Java, or C++, I found it particularly hard to get used to dynamic typing offered by JavaScript. Why? Mainly because I had to remember complex structures in my head since there are no types to document them, and no IDE is able to suggest any of their properties/attributes/members.

As TypeScript is a super-set of JavaScript – that is a language that contains all of the same features and syntax as JavaScript but builds upon it new features, being static typing probably the most remarkable of them all –  the cost of change isn't dramatic at all. The only change that needed to be done was replacing .jsx file extensions with .tsx, and since TypeScript is now well supported by React, activating it only meant running already baked npm scripts.

npm install --save typescript @types/node @types/react @types/react-dom @types/jest

However, that's not the only reason why I tried to convince my team: typing is a way of self-documenting code. On the one hand, this makes it easier to collaborate, within the same code-base, with teams that may change or grow. On the other hand this also helps to early detect type errors, that would otherwise be cumbersome to debug at later stages. Not to mention the fact that now there's no fear of erasing some not referenced mysterious property, since we know how our structures should look like thanks to TypeScript interfaces.

Despite of all the previously mentioned advantages, convincing them was no easy task. They were afraid that using TypeScript over JavaScript would signify giving up fast prototyping, modifiability, and add too much boilerplate code, thus resigning to our team agility. And they were right, but only to some extent...

• As previously mentioned, TypeScript is a super set of JavaScript which means that you can easily write a lightweight prototype for validation purposes, and later refactor it adding type annotations and all the other features TypeScript has to offer – such as the latest ECMAScript syntax.

• When it comes to modifiability,  I like to think that it acts as a supporter. Think of it this way: the added code readability and enhanced IDE experience means that changes to the code can be done faster even with the added penalty of the boilerplate code and strict type checks. But... is it too much boilerplate code?  

What's to come?

As @zohaibility from DEV notes in his article, as a statically typed language TypeScript leaves a lot of room for compiler optimizations. Nowadays the web DOM needs to be traversed in depth by the compiler to perform type inference over the DOM's nodes, so that i can carry on with execution, introducing a big performance penalty. The fact that React already has a typing system in place, means that whenever a native TypeScript compiler arrives to our browsers, big performance gains are to be seen.

If all of our code base is already written in TypeScript, this performance gain will come to our web products with almost no delay, increasing Light-it's competitive advantage.