TypeScript is one of many attempts at creating a better experience with JavaScript.
“Oh, I’m using Gulp because of reason A” or “Oh, I’m using Redux because of reason B”. You hear these sorts of things from front-end developers all the time. It’s become fashionable to use new ways of improving on JavaScript’s old faults, and that’s not a bad thing. Even ES2015 and the updates that have followed have been pretty determined attempts at righting those wrongs.
TypeScript is a promising change to our favorite language that may be having a significant impact on JavaScript’s future.
What Exactly is TypeScript?
TypeScript is a strongly-typed superset of JavaScript, which means it adds some syntactical benefits to the language while still letting you write normal JavaScript if you want to. It encourages a more declarative style of programming through things like interfaces and static typing (more on these later), offers modules and classes, and most importantly, integrates relatively well with popular JavaScript libraries and code. You could think of it as a strongly static layer over current JavaScript that has a few features to make life (and debugging especially) a bit more bearable.
TypeScript gained particular attention a few years ago because it was selected for full support by Angular 2 and following (which is also written in TypeScript itself). It’s also developed by Microsoft, which means it has the backing of two major tech companies (not a bad place for any language). Since this time, it’s gained more of a following and mainstream status.
Needless to say, TypeScript is definitely worth looking into.
How Does it Work?
TypeScript actually looks much like modern JavaScript. At the most basic level, it introduces a static typing paradigm to JavaScript, so instead of the following:
var name = “Susan”,
age = 25,
hasCode = true;
We could write the following:
let name: string = "Susan",
age: number = 25,
hasCode: boolean = true;
As you can see, there’s not a whole lot of difference here. All we’re doing is explicitly telling the system what type each variable is; we’re telling it from the get-go that name is a string and age is a number. But that just seems like we have to write more code. Why bother telling the system such specific information? Because it gives the system more information about our program, which in turn means it can catch errors that we might make further down the road.
Imagine, for instance, you have something like this in your code:
var age = 25;
age = "twenty-five";
Mutating a variable like this and changing its type will likely end up breaking stuff somewhere else, especially in a really big program, so it’s great if the compiler can catch this before we load this up in our browser and have to sit for half an hour looking for the issue ourselves. Basically, it makes our program safer and more secure from bugs.
There’s more, though. Here’s an example from the TypeScript website intro tutorial (which you can find here):
interface Person {
firstname: string;
lastname: string;
}
function greeter(person : Person):string {
return "Hello, " + person.firstname + " " + person.lastname;
}
let user = {firstname: "Jane", lastname: "User"};
document.body.innerHTML = greeter(user);
Now there are a few more unusual things here than we had before. We’ve got a run-of-the-mill object, called user, containing a first and last name, and that’s being passed to greeter() and the output inserted into the body of the document. But there is some bizarre-looking stuff in the arguments of thegreeter function, as well as something called an interface.
Let’s start with the greeter function:
function greeter(person: Person):string {
return "Hello, " + person.firstname + " " + person.lastname;
}
We can see that greeter takes a person parameter and we expect it to be of type Person. In this way, we can be sure that when we ask for that person’s first name, it will definitely be there and we won’t induce headaches upon ourselves if it fails. The :string after the function parameters tells us what type we expect this function to return when we call it.
The body of the function is nothing complicated but, of course, by now you’re probably wondering what on earth a Person type actually is. This is where the interface feature comes in:
interface Person {
firstname: string;
lastname: string;
}
Interfaces are used in TypeScript to define the structure of objects (and only objects). In this example, we’re saying that any variable of type Person must be an object containing a firstname and a lastname property, both of the string type. We’re basically creating a custom type for our object.
This is useful because it tells the compiler, as well as yourself and any developer who will work on this in the future, exactly what type of data to expect. We’re basically modelling the object properties, creating something we can reference if we need to debug later. This is often why you’ll see interfaces at the top of TypeScript files, as they give us a good idea of the data the program is working with in the rest of the file.
In our example, if we use this Person interface with a variable at any point in the program and it doesn’t contain either a firstname or lastname, both of type string (our user object thankfully does), then the compiler will moan at us and we will be forced to mend our ways.
Not only that, but having static typing means that an IDE or editor with support for TypeScript will be able to provide us with very good, very specific hinting and auto-completion so that we can develop code that is both faster and safer.
There are many more features that TypeScript allows us to use, such as generics and namespaces, so at least a quick read of their documentation is highly recommended.
Continue reading %An Introduction to TypeScript: Static Typing for the Web%
by Byron Houwens via SitePoint
