You may be asking yourself if using TypeScript for a project is a worthwhile investment of your time. The hype around it is high - frameworks and tools are supporting it and companies are adopting it.
I’ve been using TS on and off since the second generation of Angular came out and nowadays I write more TypeScript than regular JavaScript. It is currently the best choice for large codebases and I’m saying that even though I started as a sceptic.
With that said, TS is no silver bullet. You shouldn’t mindlessly use it everywhere. It’s learning curve can be steep for developers with no background in statically typed languages. Its biggest wins are only felt with time and you still need to be disciplined.
So let’s see how good TypeScript actually is.
The Tipping Point
Each new technology brings new bugs and problems to your codebase. TypeScript is not exception to that. While developers on social media preach the benefits of static types - your experience may differ.
Especially at first, TypeScript makes you go slower and you don’t see immediate value from it. It’s hard to justify the decrease in development speed.
You need to explicitly check variables for missing values and the aesthetics level of your code drops.
You find yourself trying to write the correct generic for a reduce call for an hour and you get frustrated. Instead of doing actual work - you end up writing types for trivial problems.
For people like me who are not used to working in a strictly typed language it will feel like trying to run in knee-deep water. You are doing your best but the environment around you is not letting you go faster.
Also it looks awkward.
This is the moment that some developers are put off by TypeScript. I like to call it the tipping point. You rename your files back to .js and delete any interface in sight.
Give it Some Time
Writing TypeScript should be looked at as a long term investment. You can only feel the benefits as time goes.
At first you will spend some extra time on writing down interfaces and extra checks. It’s not the most pleasant activity in software development. Especially for a JavaScript purist.
Checks are not stylish. Generics feel awkward. Error messages could be more descriptive. If you are looking for quick wins and productivity - yes, TypeScript may not be the best choice for you.
But if you are planning to work on the same codebase for more than a few months - that invested time will start paying off when you are returning to that code.
It’s hard to remember project-specific utility functions and data structures. You won’t need to remember them with TS because your editor’s intellisense will remind you.
As you are going through the first hurdles you need to remember that you are actually writing in a different programming language. Even if it’s a superset of JavaScript. Every language has its specifics and takes time to get used to.
You are usually not starting from scratch either. You decided to add TS to a project and now you’ve got errors to fix for weeks.
Figuring out types and interfaces while working in a React codebase is a different game. Don’t beat yourself if you are moving slower than expected.
Where Does TypeScript Shine?
With that said, let’s examine the long term benefits of TypeScript.
There are countless articles on the benefits of TypeScript and types in general. Safer development, better intellisense and more descriptive code are only scratching the surface. To summarise - less things to remember.
If you are working on a solo project or a module you understand your codebase well. You know the intentions and thought process that lead to the particular state of the codebase.
But to other people on your team understand those points as well? Are you sure you will remember it if you have to step away for a few months?
It’s hard to remember the structure of an object which is specific to the domain you are working in. You know what an “Order” looks like. If you create an interface for that entity - every developer that inherits that codebase will know as well.
Will you be able to recall the structure of the Redux store maintained by the other team? Having intellisense in the editor makes things much easier than using the developer tools in the browser.
It’s much easier for new team members to understand the codebase, the business and the flow of data.
Larger projects that consist of many modules or completely separate services are often owned by different teams. If something happens and you need to hop on another team to help, how quickly can you get to speed with what is going on?
You will step on some gardening equipment as you are finding your way around TS. But after the initial hurdle you will find working with it quite pleasant. Once it becomes a part of your normal flow when writing code it’s hard to deny the benefits it brings.
But to reap those benefits it’s important to not cut corners. Unless necessary avoid using the “any” keyword. Write down interfaces in the most descriptive possible manner.
Do not be afraid that your codebase will become more like Java than JavaScript. TS still manages to infer types when possible so you are not required to write them down for every variable and function.
When Not to Use TypeScript?
You are probably seeing a pattern in everything that I’ve written down so far. I’m praising TypeScript in terms of project longevity and scalability.
The benefits and strong sides shine the brightest in larger codebases or long-term projects. Apps that need to be worked on by many different teams gain the most from a readable codebase.
We need to look at the other side of the coin, though. It’s important to note “again” that TypeScript slows down development a bit. Of course, you need to write slightly more code to achieve the same end result - this is undeniable.
There is a saying in software development that everything is a trade-off. When using TypeScript we trade a bit of our speed to make sure that the project will be easier to scale and extend in the future.
When development speed is the critical factor, we can sacrifice sustainability to achieve it.
I believe that there are situations in which leaving TS on the bench (at least at the beginning) is the correct choice. If the answer to any of the following is yes, then you should probably stick to pure JavaScript for the time being.
- Is the scope/complexity of your project small?
- Is this a one-off project that will not me maintained in the future?
- Are you working on a proof of concept?
- Are you in a startup that aims to go to market as soon as possible?
For those cases, gaining speed in exchange for sustainability is a good trade-off (at least in my eyes). There is no need to spend extra time on something that will be long forgotten in a few months.
Yet, if the situation changes and you need to do further work on that project - look into TypeScript. Adding it now will be much easier than convincing the stakeholders to give you more time in the future.
- For Lambda functions whose nature is to be small, stateless and self-contained - I use good old JavaScript.
- For React applications that use Redux and have complex components - I resort to TypeScript.
- For Express services I would still pick TypeScript because I feel confident in that choice. I could see the argument for JS if the scope is small, though.
All things said, as you gain experience with TypeScript it may become an irreplaceable part of your toolset. If you and your team members are confident with it you may end up using it everywhere.
Maturity
The first time I tried TypeScript was in late 2016 when the community around it was not that large. The adoption wasn’t that high and integrating it with tools different than Angular was quite the hassle.
At the time I felt that working with TS was a zero-sum game - benefits and time costs canceled each other out.
At the time of this writing you could say that the TypeScript ecosystem is mature. Libraries now ship with types. Integration with tools is quite easy. The community is larger, so you can find learning resources or help when you encounter a problem.
There are frameworks entirely based on TypeScript and others that come with first class support for it. Upgrading to TS with some tools is a simple as renaming the file.
The team is pushing many releases per month and if Twitter is a reliable source - adoption of TypeScript across organisations is high!
One Advice to Get Started
Never use any.
If you are not familiar with TypeScript - any is the master keyword to bypass any restriction that the language opposes on you. You should avoid using it at all cost.
Using this keyword is an escape mechanism whenever you don’t feel like writing a generic or tracing a type. You can jam it anywhere where tslint is having a problem with you and you’re good to go.
This beats the purpose of using TypeScript in the first place. You bypass TS and you get no benefit from the type system. So the only thing you did was writing a few extra symbols and clutter our code.
In some situations it’s necessary - maybe a library hasn’t updated its types. But unless that is the case, avoid using it at all cost.
Summary
- TypeScript is a good long term investment.
- You will take a productivity hit at first - that’s OK.
- If you are working on a large project it’s worth to take an initial productivity hit. You’ll gain advantage in scalability and sustainability.
- For smaller apps - unless you and your team members are confident with your TS skills, you may be better of sticking to JS.
- The community around TypeScript is quite strong and growing.
- Don’t use any, unless absolutely necessary. You put in extra characters and get no benefit from TypeScript in return.
