Let us now briefly look at where JS and TS came from.
In the 1990s there was a need to make Internet websites dynamic with a scripting language suited to defining interactions among page elements in the browser.
In 1995 Brendan Eich, working for the Netscape Communications Corporation, was tasked with developing a scripting language for the company's web browser, Netscape Navigator.
We now have standardized ES modules, arrow functions with definition-based "this" binding, "spread" and "rest" operators, object notation shorthands, the predictable "const" and "let" variable declarations, and promises and async/await for handling frequent asynchronous code logic.
We even have classes in JS now, though merely as syntactic sugar over prototypes and constructor functions, a move decried by some JS developers as appealing to the OOP crowd at the expense of JS itself.
Microsoft alone might not have been enough to push TypeScript forward as a general alternative to the direct use of vanilla JS. Good for them, then, that Google released the Angular 2 framework in 2016.
Built with TS in mind and using it exclusively, through the new Angular TypeScript gained Google's imprimatur, and with it the increased confidence of the broader community.
Those include the types themselves, of course, including generics, interfaces, enums, and access modifiers - standard fare in object-oriented programming.
This makes for a smaller, shorter feedback loop and easier refactoring. It has also been argued, static typing significantly reduces the volume of tests that need to be written in order to provide program stability through sufficient coverage, since some checks are no longer needed in testing.
TypeScript can be employed gradually, not only in the sense of gradual migration of more of your project to it, but also in that the compiler can be taken from more lenient to more strict step by step. You start by using .ts extensions on your files instead of .js and go from there.
That above may sound like an unequivocal recommendation to jump aboard the TypeScript train. But things are not so simple.
Furthermore, if your project already features a build pipeline of sufficient complexity, you will have to do additional work to make sure TypeScript is well-integrated with it. Given the complicated nature of modern frontend toolchains as well as backend architectures, it may be more of a burden than benefit. There is tooling now to help handle this complexity with create-react-app, angular-cli and more, but those are not universally applicable.
TypeScript requires a time and work investment upfront. Explicitly typing your variables, function and method parameters, type parameters for generics, return types and more can obviously make things more resource-demanding. The payoff may or may not be there, and if so, then perhaps in more time than you are willing to give it.
The nature of errors caught by TypeScript is limited as well. It may be that the issues that are especially frequent and painful to deal with are not solved by proper typing. These include network- and environment-related issues, API call failures, authorization issues, unintended event behavior, and of course plain logical errors.
Something to keep in mind as well is that TypeScript does not make guarantees of runtime type-correctness. Even if your code makes the TypeScript compiler happy, you might still get runtime errors at the boundaries of the system.
Regardless, and more importantly, type correctness does not equal program correctness, and TypeScript does not guarantee the proper running of your program.
When is it right to migrate to TypeScript, or maybe the other way around? If your project and team are growing and it is hard to control the ongoing changes and you want to improve team communication - those are valid reasons for migration to TypeScript.
TypeScript has much to bring to the table in projects that utilize both client-side and server-side JS technologies, since it allows types and interfaces to be modeled reliably and with relative ease across the entire stack.
It may also be of use on backend applications specifically, especially if those tend to be heavily data-driven and can benefit from careful type-modeling.
In general, TypeScript works well in larger-scale applications managed by multiple developers. Here it can help set up and standardize mechanisms of communication and coding among team members and across teams. Thus, TypeScript can help keep code consistent and cohesive.
If a suggestion is in order, it’s this: Tools should definitely be picked with due consideration. They are there to support your work and goals, but can only do so if they are chosen carefully and used to their full potential.