LanguagesJavaScriptTypeScript: JavaScript with Safe Types

TypeScript: JavaScript with Safe Types content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

JavaScript is one of the most widely used programming languages on the planet, ranking number one for the most repositories on GitHub as well as regularly ranking in the top 10 on Tiobe’s index of programming languages. JavaScript is a scripting language, as its name suggests, which has evolved over the years. It is an interpreted, lightweight programming language that has come to support object-oriented programming as well as other styles of programming. But, for many developers, JavaScript is not perfect.

Many developers who program with JavaScript often desire to do more with typed data. This is where TypeScript comes to the rescue.

TypeScript adds data typing

TypeScript is an open source programming language that builds on top of JavaScript, allowing developers to add static type definitions. While JavaScript can infer types onto data, there are times when this isn’t good enough and more control is needed for ensuring data types operate exactly as a developer intends.

One benefit of TypeScript is that all the JavaScript features work within TypeScript. Everything you learn about the JavaScript programming language should apply in TypeScript. TypeScript simply adds a layer on top of JavaScript to allow for data typing. With this added layer, TypeScript brings a better level of checking to your JavaScript code to help make sure you are not using existing data types in a manner that is inconsistent with what is expected. That is the big difference: TypeScript adds checks for type so that you avoid possible errors.

How does TypeScript help JavaScript?

The best way to see how TypeScript helps JavaScript is to take a look at a couple of examples. Consider the following JavaScript code:

x = 32;
alert("x = " + x );
alert("Some Math: " + 64 / x );
x = "abc";
alert("x = " + x );
alert("Some Math: " + 64 / x );

In many programming languages, this code would result in a variety of errors; however, JavaScript is forgiving. For example, in the first line, x is assumed to be a new variable, and because a number is being assigned to it, it is assumed to be a number. You can see in the two lines of output in the console that x equals 32 and that the math problem in the second line results in a value of 2 being displayed. This is all done without a type being declared:

x = 32
Some Math: 2
x = abc
Some Math: NaN

In the fourth line of the code, x is assigned a string. JavaScript continues along and accepts the string, as you can see when the third line of output was displayed. Additionally, in the fourth line of output, the string is used within the division statement resulting in an NaN value because clearly you can’t divide a number by a string to get a numeric result!

While I intentionally assigned a number and a string to the same variable, that is generally not something a developer should do. It isn’t a good programming practice. In fact, most programmers would consider this a mistake and would want to know it is happening. This is where type checking and typing your data can make a difference.

In TypeScript this code would still run, because TypeScript will run JavaScript; however, it would also give you an Error: Type ‘string’ is not assignable to type ‘number’. Typescript will flag the line where “abc” is being assigned to x.

Hoisting in JavaScript

One area that can cause trouble in JavaScript is hoisting. In JavaScript, variable declarations are processed first, then other code. This means you can declare a variable after you use it (something you really shouldn’t do). The following is therefore valid and usable JavaScript code:

myname = "John Doe";
var myname = "sam";

In this code, you can see that the variable myname is not declared until the fourth line near the end. The result of this code the first time it is ran is as follows:

John Doe

As you can see, myname is printed in the console as “undefined”, then the name “John Doe” is printed finally followed by “sam”. The code does not give an error in JavaScript because hoisting causes the variable name to be declared first as if this code were:

var myname;
myname = "John Doe";
var myname = "sam";

If you attempt to run this same code in TypeScript, you’d receive an error:

Variable ‘myname’ is used before being assigned.

Catching type typos

Because most developers declare a variable before using them, you might consider the previous example frivolous. If so, consider the following snippet of valid JavaScript code, which calculates the circumference and area of a circle based on the radius provided in an object:

const myObj = { radius: 5 };
const circumference = 2 * 3.14 * myObj.radius ;
const area = 2 * 3.14 * myObj.raduis * myObj.radius;
console.log("circ: " + circumference);
console.log("area: " + area);

This code is very short and simple, so while it runs perfectly fine in JavaScript, when you see the output, the problem is very apparent:

Circ: 37.68
Area: NaN

If you were, however, to run this as TypeScript, you’d be told what the error is:

Property ‘raduis’ does not exist on type ‘{ radius: number; }’. Did you mean ‘radius’?

TypeScript Runtime Libraries vs. JavaScript Runtime Libraries

In addition to checking that types are used properly, TypeScript also adds additional types that can be used. When you compile your TypeScript code, these types are removed to create an end result of JavaScript code. In fact, TypeScript uses the JavaScript runtime libraries and adds nothing of its own to them. As such, you can use TypeScript to write type-safe code, but then compile it down to where it is just basic JavaScript.

In Summary

Just because you can do something in JavaScript doesn’t mean you should. Using data without typing is one of those things JavaScript allows that you should generally avoid. By switching to TypeScript, you can help still end up with JavaScript, but with code that is more safely typed and thus less likely to be prone to problems.


Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories