To typescript or not to typescript?
And the reason for that is simple: developers ❤ TypeScript.
Stack Overflow — Survey 2019
The Promised Land of TypeScript
Typescriptlang.org defines this language as:
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.
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.
Should your company start using TypeScript for new projects or even scarier… migrate existing codebases to the promised land of TS?
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.
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.
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.
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.
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.
Things to consider
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.
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.
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
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