Why We Use Typescript

Why We Use Typescript

If you’re a web developer familiar with the ever-changing frontend landscape, you’re likely to have heard of TypeScript by now – “but what is it and why use it?”, we hear you cry.

What is it?

TypeScript is a statically typed superset of JavaScript – which is a fancy way of saying it can do everything JavaScript can do, and more, with the added benefit of static typing. A statically typed language (in this case, TypeScript) has a type system that’s checked at compile time, and allows the compiler to reason about the code it’s compiling (e.g. it can guarantee we’re not using an integer as a string).

The TypeScript compiler transpiles to JavaScript which can be run in the browser, NodeJS, or anywhere else JavaScript can be run.

Why use it?

There are many reasons, with static typing being the flag-bearer. Static typing allows you to reason more confidently with your code and the code of others, reducing cognitive load. Explicit types also empower IDE tooling, giving you hints, warnings, and errors while you type.

Let’s look at an example in JavaScript:


JavaScript example


A simple function that capitalises the first letter of every word in a string. It works as expected when we pass in a string – but if we were to pass in a non-string, there’d be no warning. In fact, we wouldn’t really know until runtime.

We don’t like runtime errors. Runtime errors can stop an entire web app from working, they’re often unhelpful and difficult to trace, and they tend to be difficult to reproduce.

Let’s look at the same example in TypeScript:


TypeScript example


Spot the difference? Not much changed – we just specified some types. The function now explicitly requires a string as an argument, and explicitly returns a string. The closure we passed into map does the same.

Our TypeScript version works as expected when we pass in a string, but, if we were to pass in a non-string, we’d get an error at compile time. Before anything’s made it to production.


In fact, if you hook your IDE or text editor up to tsserver (a backend you can use to lint and parse TypeScript files – there are plugins/extensions for most editors), you’ll get relevant warnings and errors as you type, something you don’t get with vanilla JavaScript.

Is that it?

Nope, not even close – but in summary, the biggest additional benefits (in our opinion) are briefly summarised below.


TypeScript allows us to adhere to the concept of generic programming – we can describe how components of our app interface with other components, sans-implementation. This allows us to write reusable, maintainable, testable code far more effectively when compared to JavaScript.


ES6 introduced the concept of modules, but TypeScript expands on that with namespaces – allowing us to package definitions and functionality up for consumption internally without polluting scope. This furthers our ability to write reusable, maintainable code, compared to JavaScript.

Readonly properties

Checked at compile time, readonly properties do exactly what the name suggests: mark a property immutable after initialisation. Readonly properties allow us to more accurately describe objects, making for a more maintainable end product compared to JavaScript.


TypeScript allows us to write code that we can confidently scale and refactor, while lowering the cognitive load required to write it. We can focus more on the bigger picture – like architecture and structure – when building applications, without having to worry so much about the smaller implementation details.

In short, we love TypeScript because it has all the power and flexibility of JavaScript, with the added maturity of a strongly typed language like Java.