One of the most frustrating things about JavaScript development is the lack of a compilation step. JavaScript is an interpreted language, and therefore needs to be run in order to test that it is valid. Every JavaScript developer will tell horror stories of hours spent trying to find bugs in their code, only to find that they have missed a stray closing brace { , or a simple comma , - or even a double quote " where there should have been a single quote '. Even worse, the real headaches arrive when you misspell a property name, or unwittingly re-assign a global variable.

TypeScript will compile your code, and generate compilation errors where it finds these sort of syntax errors. This is obviously very useful, and can help to highlight errors before the JavaScript is run. In large projects, programmers will often need to do large code merges – and with today's tools doing automatic merges – it is surprising how often the compiler will pick up these types of errors.

While tools to do this sort of syntax checking – like JSLint – have been around for years, it is obviously beneficial to have these tools integrated into your IDE. Using TypeScript in a continuous integration environment will also fail a build completely when compilation errors are found – further protecting your programmers against these types of bugs.

JavaScript is not strongly typed. It is a language that is very dynamic, as it allows objects to change their properties and behavior on the fly. As an example of this, consider the following code:

var test = "this is a string";
test = 1;
test = function(a, b) {
    return a + b;
}

On the first line of this code snippet, the variable test is bound to a string. It is then assigned a number, and finally is redefined to be a function that expects two parameters. Traditional object oriented languages, however, will not allow the type of a variable to change – hence they are called strongly typed languages.

While all of the preceding code is valid JavaScript - and could be justified - it is quite easy to see how this could cause runtime errors during execution. Imagine that you were responsible for writing a library function to add two numbers, and then another developer inadvertently re-assigned your function to instead subtract these numbers.

These types of errors may be easy to spot in a few lines of code, but it becomes increasingly difficult to find and fix these as your code base, and your development team grows.

Another feature of strong typing is that the IDE you are working in can understand what type of variable you are working with, and can bring better autocomplete or Intellisense options to the fore.

var test: string = "this is a string";
test = 1;
test = function(a, b) { return a + b; }

error TS2011: Build: Cannot convert 'number' to 'string'.
error TS2011: Build: Cannot convert '(a: any, b: any) => any' to 'string'.

As we have seen, TypeScript has the ability to "annotate" JavaScript, and bring strong typing to the JavaScript development experience. But how do we strongly type existing JavaScript libraries? The answer is surprisingly simple: by creating a definition file. TypeScript uses files with a .d.ts extension as a sort of "header" file, similar to languages such as C++, to superimpose strongly typing on existing JavaScript libraries. These definition files hold information that describes each available function and variable of the library, along with their associated type annotations.

Let's take a quick look at what a definition would look like. As an example, consider a function from the popular Jasmine unit testing framework called describe:

var describe = function(description, specDefinitions) {
  return jasmine.getEnv().describe(description, specDefinitions);
};

This function has two parameters, description and specDefinitions. Just reading this JavaScript, however, does not tell us what sort of parameters these are meant to be. Is the specDefinitions argument a string, or an array of strings, a function or something else? In order to figure this out, we would need to have a look through the Jasmine documentation found at http://jasmine.github.io/2.0/introduction.html. This documentation provides us with a helpful sample of how to use this function:

describe("A suite", function () {
    it("contains spec with an expectation", function () {
        expect(true).toBe(true);
    });
});

From the documentation, then, we can easily see that the first parameter is a string, and the second parameter is a function. There is nothing in the JavaScript language, however, that forces us to conform to this API. As mentioned before, we could easily call this function with two numbers – or inadvertently switch the parameters around, sending a function first, and a string second. We will obviously start getting runtime errors if we do this, but TypeScript – using a definition file – can generate compile time errors before we even attempt to run this code.

Let's take a look at a piece of the jasmine.d.ts definition file:

declare function describe(
    description: string, specDefinitions: () => void
): void;

This is the TypeScript definition for the describe function. Firstly, declare function describe tells us that we can use a function called describe, but that the implementation of this function will be provided at runtime.

Clearly, the description parameter is strongly typed to be of type string, and the specDefinitions parameter is strongly typed to be a function that returns void. TypeScript uses the double braces () syntax to declare functions, and the fat arrow syntax to show the return type of the function. So () => void is a function that does not return anything. Finally, the describe function itself will return void.

If our code were to try and pass in a function as the first parameter, and a string as the second parameter (clearly breaking the definition of this function) as shown in the following example:

describe(() => { /* function body */}, "description");

The TypeScript compiler will immediately generate the following errors:

error TS2082: Build: Supplied parameters do not match any signature of call target: Could not apply type "string" to argument 1 which is of type () => void

This error is telling us that we are attempting to call the describe function with invalid parameters. We will look at definition files in more detail in later chapters, but this example clearly shows that TypeScript will generate errors if we attempt to use external JavaScript libraries incorrectly.

One of the fundamental principles of object-oriented programming is encapsulation: The ability to define data, as well as a set of functions that can operate on that data, into a single component. Most programming languages have the concept of a class for this purpose – providing a way to define a template for data and related functions.

Let's first take a look at a simple TypeScript class definition:

class MyClass {
    add(x, y) {
        return x + y;
    }
}

var classInstance = new MyClass();
console.log(classInstance.add(1, 2));

This code is pretty simple to read and understand. We have created a class, named MyClass, with a single function named add. To use this class, we simply create an instance of it, and call the add function with two arguments.

JavaScript, unfortunately, does not have a class keyword, but instead uses functions to reproduce the functionality of classes. Encapsulation through classes is accomplished by either using the prototype pattern, or by using the closure pattern. Understanding prototypes and the closure pattern, and using them correctly, is considered a fundamental skill when writing enterprise-scale JavaScript.

A closure is essentially a function that refers to independent variables. This means that variables defined within a closure function 'remember' the environment in which they were created. This provides JavaScript with a way to define local variables, and provide encapsulation. Writing the MyClass definition in the preceding code, using a closure in JavaScript would look something like this:

var MyClass = (function () {
    // the self-invoking function is the 
    // environment that will be remembered
    // by the closure
    function MyClass() {
        // MyClass is the inner function,
        // the closure
    MyClass.prototype.add = function (x, y) {
        return x + y;
    };
    return MyClass;
})();
var classInstance = new MyClass();
console.log("result : " + classInstance.add(1, 2));

We start with a variable called MyClass, and assign it to a function that is executed immediately – note the })(); syntax near the bottom of the code snippet. This syntax is a common way to write JavaScript in order to avoid leaking variables into the global namespace. We then define a new function named MyClass, and return this new function to the outer calling function. We then use the prototype keyword to inject a new function into the MyClass definition. This function is named add and takes two parameters, returning their sum.

The last two lines of the code show how to use this closure in JavaScript. Create an instance of the closure type, and then execute the add function. Running this in the browser will log result: 3 to the console, as expected.

Looking at the JavaScript code versus the TypeScript code, we can easily see how simple TypeScript looks, compared to the equivalent JavaScript. Remember how we mentioned that JavaScript programmers can easily misplace a brace {, or a bracket (? Take a look at the last line in the closure definition: })(); Getting one of these brackets or braces wrong can take hours of debugging to find.

A further object-oriented principle that is used in encapsulation is the concept of data hiding – the ability to have public and private variables. Private variables are meant to be hidden to the user of a particular class – as these variables should only be used by the class itself. Inadvertently exposing these variables outside of a class can easily cause runtime errors.

Unfortunately, JavaScript does not have a native way of declaring variables private. While this functionality can be emulated using closures, a lot of JavaScript programmers simply use the underscore character _ to denote a private variable. At runtime though, if you know the name of a private variable – you can easily assign a value to it. Consider the following JavaScript code:

var MyClass = (function() {
    function MyClass() {
        this._count = 0;
    }
    MyClass.prototype.countUp = function() {
        this._count ++;
    }
    MyClass.prototype.getCountUp = function() {
        return this._count;
    }
    return MyClass;
}());

var test = new MyClass();
test._count = 17;
console.log("countUp : " + test.getCountUp());

The MyClass variable is actually a closure – with a constructor function, a countUp function and a getCountUp function. The variable _count is supposed to be a private member variable, one that is used only within the scope of the closure. Using the underscore naming convention gives the user of this class some indication that the variable is private, but JavaScript will still allow you to manipulate the variable _count. Take a look at the second last line of the code snippet. We are explicitly setting the value of the supposed private variable _count to 17 – which is allowed by JavaScript, but not desired by the original creator of the class. The output of this code would be countUp: 17.

TypeScript, however, introduces the public and private keywords that can be used on class member variables. Trying to access a class member variable that has been marked as private will generate a compile time error. As an example of this, the JavaScript code above can be written in TypeScript as follows:

class MyClass {
    private _count: number;
    constructor() {
        this._count = 0;
    }
    countUp() {
        this._count++;
    }
    getCount() {
        return this._count;
    }
}

var classInstance = new MyClass();
console.log(classInstance._count);

On the second line of our code snippet, we have declared a private member variable named _count. Again, we have a constructor, a countUp and a getCount function. If we compile this TypeScript code, the compiler will generate an error:

error TS2107: Build: 'MyClass._count' is inaccessible.

This error is generated because we are trying to access the private variable _count in the last line of the code.

The TypeScript compiler, therefore, is helping us to adhere to public and private accessors – by generating a compile error when we inadvertently break this rule.