You’ve probably already heard the word “TypeScript” before. It certainly wouldn’t be a surprise; in 2018, TypeScript was the 7th most-used and the 3rd fastest-growing language on GitHub, with over 5 million weekly downloads of its compiler.
But what exactly is TypeScript?
The development community strongly associated TypeScript with Angular in the early days, despite them being distinct creations from the start. That was because Angular forces you to use TypeScript, though bypassing this is possible. We talk a bit more about the relationship between these technologies in our comparison of React and Angular.
This means you can also write React apps in TypeScript with no hassle at all!
In case you’re unfamiliar with the word, “type” is a definition that tells you the intended use of given data (for instance, we have numeric, Boolean, or string types, just to name a few).
Going into greater technical detail, TypeScript gives you:
Everything stays the way we define it. Need a variable to always be a number? It’ll always be a number, then.
A handy way of saying explicitly what type should be used.
Implicit typing performed by TypeScript itself, so that your developers don’t need to provide types where the compiler can find them on its own.
You’ll be glad to learn that TypeScript isn’t just about types.
TypeScript introduced a great deal of syntax taken from object-oriented programming, including but not limited to:
Let’s take a look at the advantages and disadvantages of TypeScript, and how they affect your frontend software development.
When discussing the benefits of TypeScript, we need to start with its most important feature: the typing system. You’ve already seen how it looks and how it works; now, we’ll show you why it’s so great.
For starters, we have compile-time errors. You may be asking yourself, “Since when are errors a good thing?” Well, errors can be advantageous when you detect them as early as possible.
Developers who code in languages like C# or Java—with highly advanced and strict type systems—like to make fun of dynamically typed languages, claiming that errors in apps written in those languages are found by the end-user, not the compiler.
But in TypeScript, when your developer makes a mistake and enters unsupported input into the code, they’ll be made aware of it before pushing the code to the repository. And even if they were to ignore that error, you also have CI/CD systems like Jenkins that can check types and prevent them from being pushed further to production.
The ability to find these obvious yet frequently occurring errors this early makes it a lot easier to manage your code with types.
Detecting errors on builds early is only one of many ways developers can benefit from types. Modern development environments like WebStorm can give you more accurate code suggestions.
Even at this level, you can be warned about having type errors in your code. Since the errors aren’t found either by the user or the compiler, but the editor itself, there’s no need for you to perform a build.
Additionally, providing types is a form of documenting code. Having even brief documentation at hand can be beneficial to your developers, at the very least because they don’t need to spend their valuable time doing it themselves. This is often referred to as “self-documenting code”—one developer writes something, and others know what it does and how just by looking at it.
Annotating types also elevates your code to the next level, since we may not always wish to look at how something works in order to use it. Most of the time, we just want to see the definition of how we can use it.
For instance, addNumbers takes two numbers and returns one number. It’s the most useful information you can get from types and code documentation, and TypeScript gives it to you straight away when writing new code.
The benefits of types naturally go beyond mere code. External libraries also work great with TypeScript. It used to be that developers needed to browse through voluminous documentation to learn where a given function is, what they can use and how, or what can be safely overridden. With TypeScript, we get all of this information directly from the development environment, which saves you a great deal of time.
The great thing about strictly typed programming languages is that they allow your developers to work on their task without relying on the other team members too much.
Having someone to ask about anything that goes in your project is admittedly one of the greatest advantages of teamwork, but doing it too often is a bad sign. Context switching and asking questions instead of writing code affects performance and causes tasks not to be delivered at the end of the sprint.
Granted, the choice of programming language by itself won’t do you much good if you’re struggling with issues like “spaghetti code” or badly defined acceptance criteria. However, it can help you along the way by providing useful problem-solving tips. It’s also imperative in getting started the right way.
On that note, TypeScript allows you to introduce new developers to your project faster. Explicitly defined data structures and type annotations make it incomparably easier to understand the decisions made by the engineers originally writing your code.
Using TypeScript increases overall performance—of individual developers and the team as a whole—and higher performance leads to better profits.
In the first section of this article, I gave you a few figures showing the popularity of TypeScript. Let’s take another look at them, but this time in greater detail.
Here’s how often TypeScript was downloaded from NPM over the last two years:
Some numbers from TypeScript’s GitHub repository:
According to StackOverflow’s 2019 survey, StackOverflow’s 2019 survey, TypeScript is currently one of the most loved programming languages, tied with Python:
Of course, these are just numbers. Popularity doesn’t necessarily mean that something is of high quality and should be trusted. Fortunately, TypeScript also enjoys support from some truly formidable players in the tech world.
As if that wasn’t enough, tech giants like Microsoft (duh!), JetBrains, eBay, Ericsson, or Ubisoft are all open about using TypeScript—and who knows how many other enterprise-level companies have included it in their tech stack.
Of course, there are no perfect things in the world, be it physical or digital. TypeScript is not exempt from this rule and it does have a few disadvantages.
In my opinion, the greatest disadvantage of TypeScript is that it can bring you a false sense of security. Yes, it’s a huge benefit that the language can check types for us and warn us when there’s something wrong with our code. However, relying on this too heavily comes with a significant risk: some developers tend to think that anything they write in TypeScript is 100% bulletproof. It’s not.
So why is it better to go with TypeScript, when Flow covers its most important feature?
Firstly, TypeScript is more popular, which means it has better support. Consequently, better support means you’re more likely to get TypeScript type definitions for external libraries than if you were using Flow.
Secondly, in 2019, Facebook decided to move Jest—one of its most popular projects—from Flow to TypeScript. I believe this speaks for itself.
Development environments support JSDoc, but it’s far from perfect. Proper typing with JSDoc is difficult and it requires a lot more code than TypeScript.
The real kicker, though, is that you can write JSDocs in TypeScript—it’s also a standard there. The only difference is that you don’t need to provide types, since TypeScript by default has better tooling for it.
Over the years, we’ve seen a number of languages that provide a strict type system and can be compiled to frontend code one way or another:
That’s because the most advanced development environments like WebStorm are using TypeScript type definitions to facilitate code development using external libraries.
Of course, that’s only a partial benefit. The current situation makes the job a little easier for your developers, but it still doesn’t give you all the good stuff like type checking.
Therefore, before you move your project to TypeScript, there’s one more key question for us to answer: can ongoing projects move easily to TypeScript?
The answer is: yes, they can. What’s more, the transition likely won’t be as time-consuming as it may seem! Here are two ways to perform a migration of this kind.
Simply rewriting all of your code to TypeScript may seem like the most obvious way to make the transition, but it’s also the most difficult and time-consuming (at least in the beginning).
It’s absolutely doable. However, this all-hands-on-deck approach is best suited for small projects and small teams. This isn’t work you can easily parallelize, and you have to put your development on hold for the duration of the process, so it won’t be possible for you to implement new features at the same time.
This is great, because it means you don’t actually need to move your whole project at once. All your team needs to do is spend a few hours configuring TypeScript in your project and move some basic code around—that’s it!
This way works best for medium- and large-sized projects with a lot of people in the mix. It takes next to no time at first, and your developers can start reaping the benefits of TypeScript straight away.
Despite those small drawbacks, I’d still recommend choosing this way if you decide to include TypeScript in your ongoing project.
Most importantly, TypeScript offers tangible benefits for both your developers and project stakeholders. By writing just a little more code, the language helps your teams quickly achieve better overall performance: fewer bugs, faster releases, more confidence in the code quality.
Will your project be the next in line to join the frontend revolution? It’s up to you to decide!
Thank you for reading our article on the benefits of using TypeScript for your frontend development. We hope you’re going to give this awesome solution a shot in your next software project.
Do you have any questions or comments about TypeScript or software development in general? Feel free to drop them below, and we’ll happily get back to you.