TypeScript is a "superset" of JavaScript; A program written in JavaScript is already a valid TypeScript code. In addition to its usual code, you can add type annotations, and declare variables like "string", "number", etc. We'll explore why you'd want this together.
It may seem strange to introduce "more compilation errors" as an advantage. But in recent years, JavaScript is increasingly used for the development of large applications and libraries - the language that was adapted to write small scripts on a handful of lines is beginning to seriously grow out of their shoes in dealing with issues like modularity, complex dependencies, and thousands or hundreds of thousands of lines of code. In such a situation, it is good to have early errors in compilation than to break things while driving.
Imagine JavaScript is a pen. You're not so excited about it, but it can at least put ink on paper so you can do your job. TypeScript is when someone says to you "Here, use this pen instead: it does the same things as your old pen, but it helps you write correctly and also gives you some handy tips on what works and what needs to be fixed".
TypeScript is a better version of JavaScript?
In the end, you will be able to submit higher quality work, as TypeScript has already found a lot of mistakes along the way that you do not need to run the program to detect. And you can work faster, more efficiently, and with greater confidence that things get right.
One thing I've realized on the road is that there's not much about "errors found during compilation" like "errors found while writing the code." Modern development environments like Visual Studio and WebStorm have excellent support for finding errors and giving tips about one's code while writing. People who come from the major static languages are already familiar with this, and it is usually felt like TypeScript restores the order a little after missing IntelliSense in regular JavaScript.
In StackOverflow's survey 2016, TypeScript came one in response to the question "Which technology would you prefer to use?". It is remarkable for a language to climb to first place in just a few years. It shows little that there is a real need for TypeScript; that you see the value.
Okay, but what's the chin? Why do not all TypeScript use? Are there any disadvantages? Anders Hejlsberg (Creator of TypeScript) got that issue in a podcast once. His response was "TypeScript is a value proposition that is not rational to say no to". You can type the same JavaScript code as you did before, but you get early warnings about things that can go wrong or will go wrong, or just be risky or problematic in any way.
In reality, a decision like "switch to TypeScript" is always taken in a context. You have existing JavaScript code, external dependencies, etc. Even in such a situation, there are good opportunities to consider TypeScript. For example, an existing project can choose to migrate source file for source file; TypeScript is smooth enough to manage a code base with a mix of JavaScript and TypeScript code. You also choose to use different configuration flags how strictly you want TypeScript to be with one's code. There, one can balance between stricter / better type controls on the one hand, and easier migration on the other hand.
I've heard that using Flow instead. Is it true?
Flow is an interesting option with about the same selling points as TypeScript. (Flow is developed by Facebook and TypeScript by Microsoft. Both are open source.) However, it is quite clear that TypeScript has "won" in the sense that it has a large community and lots of support from all directions. A little like the situation with Git and Mercurial; The latter is a good alternative, but it has a significantly smaller market share.
You have done a course for people who want to know more about TypeScript?
Yes! In this course you can clearly see how JavaScript has grown, and how to combine the best of TypeScript, modern tools, test-driven development, and modern development methods to build non-trivial software for the browser and for Node.js.