EDIT 07/20/2020 : Thank you all for your feedback. I'm definitely going to invest some time in some TypeScript education in the long run. Apart from all the points you made in your responses (static typing, compilation, codebase consistency, etc ...), the fact that Deno may go big (which I hope, the improvements over Node.js could be life changing) and that Visual Studio Code (which I use) is built on top of Electron using TypeScript is what convinces me.
So the main benefit that TypeScript brings is static typing. You make your code more explicit, thereby limiting the number of unintentional behaviors that are possible. The compilers type checker can suddenly take care of testing these extra constraints for you and you start removing this burden from your unit tests. As a matter of fact TypeScript has a pretty advanced type system, a magnitude better than the current Java version (14) or Go-lang. One of these features are union types (aka. coproduct, sum type, etc). This lets you represent your types as "this thing" or "this other thing". Returning a disjoint union can make your code even more explicit and thus further limiting the number of unintentional behaviors. A simple example of this is the
head function that returns the first element of a list. Either you get the value or you get undefined if the list is empty. A better approach is to return a
Maybe type which is either an instance of
Nothing. This tells you that the code calling
head needs to handle exactly two possible cases. Languages with even stronger type systems like Elm and Haskell can even enforce that your code won't compile unless you handle all the possible cases for any union type. So again the compiler helps you avoid more runtime errors.
So to conclude the benefits of using a language with strong static typing:
- Compiler helps you avoid runtime errors
- Substantially reduce number of explicit unit tests
- Better security and reliability by preventing unintentional behavior
- Let's you refactor code with confidence
- Code becomes more self-documenting
The unintended behaviour of addition (or not knowing the gotchas) on web-browser have always got FE devs scratching their head. I never really got a chance to work on an actual TS project professionally, but having worked with Node.js quite a lot and later moving to Java (mostly for web services), I just didn't want to move back to Node.js. But TS is definitely a game-changer.
Unfortunately there is too much "quick and dirty" rather than "correct, secure and reliable" in our industry.
I've been feeling the same way and it was almost too simple for me. First, strongly typed languages are objectively better for catching errors during development instead of during production so a small amount of work upfront pays huge dividends later. But the easy part is how actionable it is.
Find a codebase that you want to convert. For me, it was a server that I wanted to convert to Firebase cloud functions to go serverless. I took my server.js file and copied it as server.ts. I created a simple tsconfig.json file in the root with some standard settings online and then I let the VS Code IntelliSense guide the migration. It was so much easier than I expected and I learned TypeScript as I was converting my codebase.
It was almost too easy and now I have all of the benefits of feature-rich and built-in assistance in my code-editor. Documentation on hover, clear and clean errors. This was only about 2 weeks ago and I am not sure I'd ever go back to Vanilla JS now. It was love at first use with me.