We have to admit it – TypeScript is a big thing for the JavaScript community! Many developers cheerfully welcomed Microsoft’s decision to put efforts in that direction. It brought peace of mind to larger teams and projects. It’s fast, safe, secure, and can handle complex problems. Almost all of the top used open-source libraries are (being) rewritten in TypeScript. It’s trying to become the de facto language to use on the web (and not only).
And of course, there’s a “but”! Like every other technology – it’s not a silver bullet. It can save you, but it can also ruin your project, team productivity, or the codebase.
This article is trying to showcase the critical dilemmas you’ll need to face when thinking about using TypeScript. It’s an effort to make you ask yourself, “should I use it” before jumping the hype.
Is TypeScript really bad?
Absolutely not, and this article should not be considered a list of drawbacks! TypeScript is a perfect tool in specific cases.
A simple example of when to use TypeScript is a system where you have a lot of data passed around, e.g. frontend SPA (Single-Page Application) dealing with API calls. Of course, if the backend changes, then TypeScript won’t save you.
However, it will bring clarity and improve the development experience. People will know what kind of data comes in, how it’s transformed, and how it’s being sent back.
Developer satisfaction and ease of use are essential things to consider!
Is the team ready?
The basics of TypeScript are straightforward. But rewriting your entire application using TypeScript opens the door for unexpected troubles. As simple as they seem, generics might result in a few hundred character function definition. Covariance and Contravariance are a thing.
Your team needs to be ready. Everyone should have passed at least some sort of educational process. Because otherwise, it becomes more problematic than helpful.
Is development fast enough?
If the team consists of highly qualified senior developers, you might not notice the difference. But figuring out all those typings takes time.
You cannot build your project if the types are wrong. You cannot test it. Probably you cannot push it. It needs patience and skill to master.
Keep in mind that TypeScript will make the development process a bit slower in almost all cases. Can you afford that?
Will TypeScript solve my problems?
TypeScript aims to solve particular problems and “Type safety” is probably the most important one. But is it really safe or does it create (attention, buzzword!) a false sense of security?
TypeScript helps you with “safety” until your code compiles. Then, it’s JavaScript. Whatever data structure comes from an operation, it cannot help. If you want to verify the structure of the parameter object, then you need to do that manually. The IDE will give you hints during development, but all those interfaces will be stripped down when the code is transpiled.
Additionally, TypeScript can help you when there’s a lot to remember or when the level of abstraction is high. Developers won’t need to remember all the nitpicks and small hacks someone else did. This makes TypeScript an excellent tool for larger projects or teams.
So the question you want to ask yourself is “What kind of problems do I want TypeScript to help me solve?” Is it capable of doing so?
Do I want to stick with TypeScript?
Let’s be honest – rewriting to and from TypeScript is neither fun nor easy. It takes time, patience, and is prone to errors. From my experience, I can say that you’ll be stuck to it if you make that decision. Is it worth it? Can you quickly rewrite the code if needed? Can you create and maintain the pipelines and local setup for fast compilation?
ТypeScript sure stirred up the ecosystem. But JavaScript moved on, and it started improving. We’ve seen immense effort to upgrade what seemed like a dinosaur-aged technology. We’re even seeing a Type Annotations ECMAScript proposal!
Can you afford to stick to this technology?
Is another technology more suitable?
TypeScript transpiles to JavaScript. It’s a language that you write in, but in the end, you get JavaScript.
Think about why you need it, and then if there’s a better tech/language that you can use instead? Typesafe? Multi-threading, memory efficiency, reliability, security? There are plenty of options, including Java, Rust, Go, and many more.
TypeScript’s goal is to improveJavaScript. The code is stripped down of all your types and goes to plain old JS. Do you need this kind of improvement, or do you need something else?
Does my project need TypeScript?
This one is harder to explain and is more opinionated. But we must define the business needs and decide if TypeScripts fits into those.
Is the business ready for slower development and probably a specific domain knowledge when hiring new team members? Is any data being sent through various sources that I would like to define explicitly?
Some projects don’t need TypeScript, and that’s fine! They can be too small or very specific. It can be backend code that runs on Node and does not have heavy data structures. Or it might be an open-source project that you would like an old system to be still able to use easily.
So, how helpful might TypeScript be to your project, and how crucial will it become for the development process? Are the gains more than the drawbacks?
