The case for adding TypeScript to your JavaScript Applications
By: Zachary Ernst
Tags: JavaScript, Typescript

The case for adding TypeScript to your JavaScript Applications

History

Undeniably, JavaScript is the programming language of choice for most web developers, and it has been the “language of the internet,” for over two decades. During the early days of the internet, websites were mostly static pages, using HTML and some basic styling; a client would make a request to a server, and the server would respond with these static pages. However, it was the desire of many early web-developers to make these websites more dynamic in nature.

One specific person, Marc Andreessen, who was the founder of Netscape Communications, believed that websites with animations and interactivity would be the “web of the future.”¹ This was at a time when Netscape was becoming more popular on the web with their browser “Netscape Communicator.” There was a need for a scripting language to make simple changes to the DOM (Document Object Model) used by static websites; this language needed to be easy-to-use and cater to people who “designed,” rather than those who “programmed.” In came Brendan Eich, who worked with Netscape to create “Mocha,” which later became “LiveScript,” and finally “JavaScript.” Many of the features JavaScript is still known for today were designed into the language from the very beginning.

As JavaScript has grown over its many years of web scripting, it has expanded its functionality as a language capable of operating in many more paradigms than it was originally intended. These include: server applications (node.js), mobile applications (React-Native) and even desktop applications (electron.js). As this once simple-language has expanded itself, many of its inherent limitations have surfaced and has caused frustration among those who prefer to work with more “traditional” programming languages such as Java and C#; this is even more apparent when enterprise-level server applications are created using these languages as opposed to JavaScript. What is it about these programming languages that make them easier to use for many programmers?

JavaScript Limitations

Perhaps the most notable limitation that JavaScript has in its traditional form is its lack of “type-checking,” that is part of the syntax of many other languages. What exactly is this? In simple terms, type checking allows for pieces of your code to be checked for type safety before it is compiled. This means that if a variable is being placed in a part of your application, where it will not perform correctly because its “type,” is invalid, then this will be apparent before the build of that application. In JavaScript, there is no checking for the type of an input variable.

A very simple example of this is when math is being performed on a variable being input into a function:

const addNumbers = (num) => {

return num + 1;

}

In JavaScript, if that input variable is (or could be) a string, such as “1”, then this would produce unexpected results, and not even warn the programmer of this possibility before the program starts running. While “if” statements could be used in many places to account for this, it is certainly a cumbersome solution, and definitely not the preferred solution for JavaScript programmers.

In Comes TypeScript

So the question becomes: how can we combine the more sophisticated features that many other languages support (such as this type safety) while still using a familiar JavaScript syntax? This is where TypeScript has become the primary choice for many would-be JavaScript programmers. TypeScript is an open source superset of JavaScript that was created by and is maintained by Microsoft. In a TypeScript application, this same code would be written as:

const addNumbers = (num: number): number => {

return num + 1;

}

In this specific example, the input variable “num” is explicitly stated that it must be the type “number,” which appears after the colon. The second “number,” is stating that the return type of the function must be a number. If you were to call this function in a TypeScript program in such a way where the input type is not a number, or the return of the function is not being used as a number, then an error will occur before it is compiled into vanilla JavaScript. Furthermore, in many IDEs (Integrated Development Environments) a linter will actually warn you of this error while you write it out.

TypeScript Example: Interface

Another prime case of using TypeScript effectively is using the type “Interface.” The main purpose of an Interface is to type-check the shape of a value; this can be referred to as “duck typing” or “structural typing.”² When would something like this be useful? In many cases, when you are dealing with objects in JavaScript, you will call on certain values within an object. However, when dealing with the values of a key within an object variable, many times programmers will run into an “undefined” error. This is because they attempt to manipulate the value of a key of which is not contained within that object. As an example, take the below code:

const person = {

name: “Erin”,

};

return person.age.toString();

In this instance, we are calling on the “age” key which is not inherently contained within the “person” object. If someone were to run this code as-is, while the IDE will most likely not show this error, once it is run, one would discover a common error:

TypeError: Cannot read property ‘toString’ of undefined.

From viewing this code in this instance, it is obvious to us that this would happen. However, what if the toString function was only called sparingly within a Node server or in a React application? The programmer would never see this error until this function was called in an edge-case, at which point it has already created a poor user experience if this was not caught in testing. This can especially happen when objects are manipulated within functions. TypeScript Interfaces would help with this type of problem, by allowing us to define what a “Person” should look like. Take the following TypeScript code:

interface Person {

name: string,

age: number

}

const erin: Person = {

name: “Erin”

}

return erin.age.toString();

In this instance, while the linter will not pick-up in the toString error that is obvious here, it will tell us that the variable “erin” is missing a property “age;” the error would look like this:

Property ‘age’ is missing in type ‘{ name: string; }’ but required in type ‘Person’.

In addition, you also define what the type of each property should be. As you can see from this case, being able to define what an object can look like ahead of declaring it will help alleviate many undefined errors that could occur.

Some Statistics

Let’s take a look at one real-world example of TypeScript being used in a large tech company. AirBnB is one such business that has made the use of TypeScript and its features. As noted in the photo below, when AirBnB’s code was analyzed it was determined that they could reduce their bug-count by about 38%. Considering the size of their code-base, this is a significant margin.

Perhaps an important question to be asked overall when learning a new technology is how popular it is currently, and how much that popularity will grow and be in-demand. It is no secret that TypeScript is becoming much more popular over time. Between 2016 and 2018 alone, TypeScript rose from 20.8% to 46.7% on Google Trends.³

Conclusion

As can be seen from these specific examples, TypeScript is an extraordinarily useful tool when working with a JavaScript application. Some might argue that TypeScript is noticeably more verbose to code than vanilla JavaScript, and that it is not worth the time and effort to add these features to your application. Perhaps with very small applications, this might be the case, as the time debugging the code could be less than adding in all the necessary types. However, even for medium-sized applications, TypeScript is incredibly useful to make sure parts of your application are safe from errors, as well as keeping your code organized and uniform. This is especially the case when working with other people, and types and “shapes” of your code need to remain consistent and decided upon prior to putting pieces of it together. There are many costs and benefits of using TypeScript, mainly the cost of time coding, the amount of bugs that can be avoided by using it and how critical program-correctness is required. However, for most cases of larger JavaScript programs, programmers will find the use of TypeScript to be well worth any extra syntax needed for it.

[1] Sebastian Peyrott. (January 16, 2017). A Brief History of JavaScript https://auth0.com/blog/a-brief-history-of-JavaScript/

[2] TypeScript Documentation. https://www.typescriptlang.org/docs/handbook/interfaces.html

[3] Saurabh Barot. (July 19, 2019). Why Developers Love to Use TypeScript in 2021? https://aglowiditsolutions.com/blog/why-use-TypeScript/#:~:text=Popularity%20of%20TypeScript,from%2020.8%25%20to%2046.7%25.