Here’s the thing though, the only time you are forced to use, for example, Typescript is when you are contributing back to the Open Source library you are using, or perhaps when you join a team that is already using it. It’s not like anyone is holding a gun at your head to use it (CoffeeScript, on the other hand, is the spawn of a demon).
Here’s why I like using TypeScript:
- It removes the need for a separate pre-build linting step. The TypeScript transpiler is always linting for you. Additionally, we are catching more errors at design-time compared to using a traditional linter.
- It allows me to express the API documentation in a way the compiler can interpret. DocBlocks are good, but design-time checking is better. Good type-hinting improves our productivity.
To be fair, there is a learning curve for the syntactic sugar that TypeScript brings to the table, but for me it’s been an extremely profitable return on investment.
To be honest though, an article like this needs to show end-to-end (design to deploy) example code to demonstrate your points better (and evaluate the relative tradeoffs). You also need to consider whether you are pitching to a hobbyist that is just using code for oneself, or code that is passing through dozens of hands in a large project. You can (though I still don’t) cut corners when it’s your code you are writing for yourself (despite what your future self may think about you). It’s another thing entirely when you are writing code that other people may have to read and debug.