TypeScript is a fairly new programming language. It was released in 2012 by Microsoft and since then it’s become widely used. It’s taken over a good portion of the frontend in large-scale applications, and all it is is a new and improved version of JavaScript.

The nice thing about TypeScript is that it’s completely interchangeable with JavaScript. In fact, any TypeScript code you write can be translated into native JavaScript code. That means that you can use any JavaScript inside of TypeScript, and use all of the features of TypeScript as well. Then when it actually comes the time to run your code, it will get translated into a native JavaScript file which you can then run.

This is really powerful because it means that if you want to change JavaScript files to TypeScript files, it’s really easy to do that, and the same goes for the other direction (TypeScript to JavaScript).

When and how to use it

TypeScript is best for large-scale projects and enterprise-level applications. Using it for small-scale projects with one or two JS files may be overkill. 

On the other hand, when you have a lot of code in your program, many things going on, and multiple people contributing, TypeScript really shines because of the features it adds to JavaScript. If you know JavaScript, you pretty much already know TypeScript. Anything you can write in native JavaScript, almost line for a line you can write the exact same in TypeScript. Then the core feature it adds is actually the ability to add static typing to JavaScript. So this does not change the fact that JavaScript is a dynamically typed language and it doesn’t change that when it comes to actually running this code. But it means that when you’re writing TypeScript code, you have type enforcement and you can choose if you want to declare the type of variables, method parameters, return types, or whatever it may be.

Transpiling

In order to use TypeScript, it first needs to be converted into JavaScript. We call this conversion transpiling. You may have already come across compiling, which is a general term for taking source code written in one language and transforming it into another language. Transpiling is a specific way of compiling, which takes source code in one language and transforms it into a language with a similar level of abstraction. When we’re talking about compiling, especially in languages like Java, we usually mean translating the source code into something more machine-readable, i.e. something that the computer understands and can work with. When we’re talking about transpiling and similar levels of abstraction, that means that the level to which we are translating the code doesn’t change that much in terms of how machine-readable it is.

There are multiple ways of transpiling TypeScript into JavaScript, all done in the background.

One way is to let your IDE do that for you, usually via an extension to the IDE. The way you use the extensions can vary greatly. They can provide a UI to configure the various options, or they can use a tsconfig.json file to do so. And they can also provide a button for the conversion, do it automatically on save with their own file watchers, or provide a command to use it via the command line.

Another way is to use TypeScript’s utility called tsc with which you can both create a tsconfig.json file, which contains the configuration for the transpiler, and also transpile the code. The last way is using a 3rd party tool like Babel. Babel is a popular transpiler for JavaScript code. It checks what code was written, which browsers we want to support, which features are working in which browsers, and what code needs to be transpiled.

The importance of static typing

The reason static typing is so important is that it comes with so many different advantages. When you have static typing and you have type enforcement, the first thing that’s a really big deal is that catching errors becomes a lot easier and writing bad code a lot harder. In a language like Python or JavaScript, that’s dynamically typed, almost all your errors are happening at runtime. Now, that’s not a good thing. You often don’t want to get your errors at runtime, because that means, first of all, that you have to figure out what exactly is happening at runtime. Which is more complicated than while compiling, but there are also chances that you may miss errors because they just haven’t run yet.

With TypeScript, most of the errors that you’re commonly getting at runtime in a dynamically typed language are gone, because now these errors are being shown to you before you can run the program, so you are forced to fix them if you want to run the code. If you’re debugging something at runtime, you probably need a debugger, which you might not have access to or fully understand how to use, so it’s much harder to do that at runtime, with so many other things to consider. You have to track down where in your code that is actually happening from, and there are so many possible issues when you’re not catching these bugs while compiling.

And when you’re working on large-scale software that’s going out to clients and users, you want to make sure that you caught and fixed all those bugs, and that you’re getting them in your IDE before you actually go to the software.

Work smarter, not harder

The idea is that if you give your IDE more information about your code, it can do more work for you. If you can have your IDE carry a lot of the weight and do a lot of the work, you’re saving yourself both time and money, to actually code. You want to get that done as fast and precise as possible, and that is the core advantage of TypeScript.

Optional typing

TypeScript comes with a lot of other really great features too, but the one that most people like about TypeScript is that typing is completely optional. Some people might think that having to declare the types will be a pain, but it’s really not that difficult. And being optional, you can have two people working on the same code, one person working strictly with types, and the other person not using them at all, and, while it may not be the ideal solution, their code will still be compatible. There may be potential issues, of course, but the concept is that it’s optional, so if it doesn’t make sense to declare types, you don’t have to do that. And, you can still use the other advantages of TypeScript. In other programming languages that are actually truly statically typed, you would, of course, have to do that.