At this point you, I, and… well basically every developer in the world has heard of TypeScript. It has been part of the JavaScript world for a few years and its increase in popularity has shown no signs of slowing ever since its inception.

And the reason for that is simple: developers ❤ TypeScript.

Stack Overflow — Survey 2019

The Promised Land of TypeScript

Typescriptlang.org defines this language as:

JavaScript that scales.

This definition might appear vague, but that’s all TypeScript is. Although it is important to know that this is not related to the performance of the code.

TypeScript and JavaScript have the same performance, this is because at the end TS will compile to plain JS. Therefore — if the time ever comes — for a different technological need, you will not be looking to migrate from JS to TS.

Then…

Why use TypeScript if it just compiles to JavaScript at the end?

In simple words TypeScript is a better JavaScript, this is in terms of the codebase. Which is the key reason why developers choose this language over its more rebellious brother.

When choosing a language for your company, besides technological requirements, there are two very important points that must be considered:

• Existence of developers for this particular language (in good amounts and quality): TypeSript ✅

• It is not a trendy language that might be irrelevant in a few years. TypeScript is backed by Microsoft, plus it’s the main language of Angular (backed by Google) and many companies are migrating their JS codebases to TS, therefore: TypeScript ✅

Google Trends — TypeScript popularity in the last 5 years.

Better Codebase

Should your company start using TypeScript for new projects or even scarier… migrate existing codebases to the promised land of TS?

My short answer is: Yes. In the end, it’s better if you can do things right from the start, as long as it doesn’t compromise on the deliverability. This is what we realized early on at my previous company, in choosing TypeScript over JavaScript, and it has benefited us significantly as we have grown — more on this later.

Every company has different strategies regarding how to become profitable, and sometimes during the strategy definition mistakes are made. One of these strategies could be to write code fast with the intention of refactoring at a later stage. Because you know, that’s what Twitter and other big companies did, right? Well, not really.

The reality of a company like Twitter, is that they are in a different place than when they started, therefore different technology is required — this is in the context of performance scalability.

If the time ever comes that your company needs to rewrite a service due to a technical requirement. TypeScript will allow for an easier refactor over JavaScript because TS encourages developers for structuring the code in a more human-readable manner by having types and interfaces.

Example #1 — Interface

TypeScript — Interface example

In the example above, we can appreciate what could represent a product interface. So, rather than inferring it later on when working with a product, this interface will represent all properties and methods we have available.

Faster and more predictable development.

You might have been told that when using TypeScript, the development will be more tedious — given that you have to work with types, interfaces and follow a more structured approach to writing code.

Hence, slowing development of features that could be achieved with — less time and lines of code by using JavaScript.

Well, let me explain my experience with TypeScript… Imagine every time you write code, let’s say in JavaScript, it was done in a similar fashion to pair programming, there are two pairs of eyes looking at the code that is being written on the screen.

If there’s a typo and the developer didn’t spot it at first, most likely the programming partner will notice and alert of this issue — Otherwise you’ll have to compile your code, run the app that you are building and watch it fail or not work as expected. Then start debugging to find out it was a simple typo in your code.

Typed languages like TypeScript help avoid this — by notifying you at compile time of issues with the code. Plus the IDE would probably let you know about these issues even before compile-time, thanks to types and interfaces.

Example #2 — Types

TypeScript — Type example

In this second example, we have an arrow function called foo that returns an object with three properties.

Rather than creating an interface for the return of foo, TypeScript allows generating a type based on what is returned from a function (see line 11).

Auto documented code (…sort of)

Types are one of the best forms of passive documentation you can have.

Onboarding new members

At my previous company, we ran a microservices architecture with several frontend apps, therefore we use different languages across our codebase.

Some services are written in TypeScript, Go, and others (mostly frontend apps) written in pure JavaScript. When I joined the company and I had the onboarding to the company’s codebase, I can say with certainty that it was definitely easier for the services written in TS due to its nature of encouraging developers to structure the code in a more human-readable way.

This phenomenon I noticed it was also true for all the new team members of the company, even if they had no prior experience with TypeScript.

Generally, it took a lot of time and effort to understand the frontends written in JavaScript for a proper onboarding, including the engineers that worked directly with the JavaScript code also had a hard time remembering what was going on at times, due to the abstraction JS allows.

Code review

Reviewing someone else’s JS is also challenging, especially since you need to auto-infer all the types, which is an additional process besides understanding the code you are reviewing.

With TypeScript, I can assure you it is much simpler to review someone else’s code. You don’t need to infer the return type of a function, or what arguments are been passed. It’s right there for you to read.

Comic “Pull Request” from https://www.monkeyuser.com/

Static languages have a proven ability to enhance code quality and understandability, by passively documenting the code with types, interfaces, and a better code structure.

Note: We no longer use pure JavaScript in any of our services or frontend apps, and probably will never look back.

Things to consider

Although TypeScript sounds like a perfect solution for most of the problems JavaScript has, there are some points you should be aware of, especially if you come from typed languages such as C# or Java.

• Since TypeScript compiles to plain JavaScript, types do not carry over this process, therefore they do NOT exist in runtime.

• You could still “hack” the type system by force type-casting or use of any when developers are feeling lazy.

• You can use JS libraries with TS, but you might encounter that not all of them will have type definitions available, therefore your team might be forced to either create them and maintain them or cast everything to any. Which may introduce inconsistency with the codebase.

Conclusion

If you foresee a successful future for your company, with multiple engineers joining the team, features being developed actively for the company’s product, and all that comes with delivering for a growing user base, TypeScript is your friend.

Although TypeScript is not a perfect language, it has clear advantages over JavaScript, while maintaining most of what makes JS awesome.

• Typed language

• Better structure codebase

• Allows for easier migration to other languages if needed in the future

• Faster and less buggy development experience

• Easier onboarding for new members

• Auto documented code

• Better code reviews

• All JavaScript libraries available

• One language for Back End and Front End

• High adoption trend (+160% from 2018–2019 according to GitHub)

Just like in any other engineering in the world, the result of a project will always be influenced by the base that it was built on.

“If I had nine hours to chop down a tree, I’d spend the first six sharpening my axe.”

— Abraham Lincoln