Last week, we had a Lunch & Learn session on Zoom, which is basically a learning/sharing type of online workshop. Every week, we encourage colleagues to share their insight into different topics that we can all learn from.
I hosted this “Intro to TypeScript” workshop for those of us who’ve never used it before and I thought it would be a great read for our online audience as well.
What is TypeScript?
To start with a definition:
Or, even better:
Let’s break the first definition down into 3 key terms that warrant some additional explanation.
Static types vs. dynamic types
Most developers probably use one or the other over the course of their career, so it may take some effort to revisit some college knowledge from when we were taught static types. What’s important to remember is that there are 2 major differences between the two, which trigger a series of side effects.
First of all, statically typed languages perform type checking at compile time. This enables our IDE (Integrated Development Environment) to compile the code continuously, which, in turn, allows us to catch errors early on.
Dynamically typed languages, on the other hand, perform type checking at runtime. This can lead to delays in finding errors during execution.
The second major difference is that, in a statically typed language, the developer has to declare the types of variables before using them. Consequently, variables are prevented from changing types, which further defends against unintended errors. That’s why static types offer IDEs more information about your code, enabling them to make better-informed suggestions and safer refactoring. It’s true that certain statically typed languages (such as Typescript) can use type inference to identify the type of a variable when you initialize it.
Dynamic types allow for variables to change types, offering more flexibility, but sometimes this creates unexpected errors.
In a simplistic way of looking at this, each edition of the ECMAScript specification (from ES3 to ES10) builds upon the previous, and TypeScript implements all of these and more.
Now let’s go through some FAQs:
What else is “super” in TypeScript?
Besides type checking, TypeScript adds features from ES6, ES7, ES8, etc. without needing additional transpilation.
Compilation vs. transpilation
We used the term “compile” a lot but the more accurate term would be “transpile”, when it comes to TypeScript. The source code remains human-readable and at the same abstraction level.
The transpilation process has three main stages:
- Parsing: the computer reads and understands our code using a certain level of abstraction
- Transforming: it takes that information and transforms it into an AST (abstract syntax tree)
- Generating: the code from the new language is generated (it’s important to note here that TypeScript does not automatically add polyfills)
Myths and facts about TypeScript
Myth#1: It requires a longer onboarding process for new developers
There are actually fewer boilerplate tests needed with Typescript. In my opinion, it takes less time to onboard a new developer because there’s a smaller knowledge base to transfer. If that person isn’t familiar with TypeScript at all, on the other hand, there is a bit of a learning curve.
Myth #2: It complicates maintenance / it makes it harder to edit the app in the future
Actually, TypeScript code is easier to refactor. In my experience, maintenance takes the same amount of effort as with any project.
Myth #3: It introduces a lot of conflicts with React
Nowadays, it makes it easier to work with React. While this might have been true in the early days of TypeScript, in the past 3-4 years, the majority of libraries have either migrated their code to TypeScript or they’ve had type declaration files (typings) created for them.
Myth #4: It increases development time
Additionally, some libraries still don’t have typings, which means that sometimes developers might have to write their own, search for a different library, or choose to use `any` for the library and give up the benefits of typescript for that library.
Myth #5: You run the risk of locking-in the project to some hipstery tech that won’t exist a year from now
TypeScript is now 7 years old and it’s not giving any signs of going away. It is actually one of the fastest-growing languages. “We’re seeing trends toward more statically typed languages focused on thread safety and interoperability. Kotlin, TypeScript, and Rust are growing fast this year,” GitHub stated in their Octoverse Report last year.
Myth #7: It makes it impossible to bring code from non-TypeScript codebases
If this article has piqued your interest on TypeScript and you want to explore it further, I’d recommend the official documentation available here.
What are your thoughts and experiences with TypeScript so far?
YOU MIGHT ALSO BE INTERESTED IN
Kicking off new projects
The ABC of starting a new software project, complete with best practices, how-tos, and other resources.