But why did I do that?
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.
- 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.