When Not To Use TypeScript

TypeScript is great but sometimes, using it can turn out to be an unnecessary waste of time.

Sonny Recio
Bits and Pieces

--

Being a former C# programmer, I’m a big fan of TypeScript and strongly-typed programming languages — having said that, I know better than to use it in every project. In this article, we’ll go through the times where TypeScipt serves its purpose perfectly and other times where using it is an unnecessary waste of time.

TypeScript is good since it might save you a lot of headaches when it comes to debugging your JavaScript during compilation time, but not when you’re using it for the wrong reasons. Like any other tool, to build an app, we need to know first what are the things we have to do before delving deeper in using it.

Want to know when not to use TypeScript? Let us first define what TypeScript is.

Before we do so — a useful tip: Use Bit to encapsulate components with all their dependencies and setup. Build truly modular applications with better code reuse, simpler maintenance and less overhead. Share and collaborate on individual components across applications, to build faster as a team.

What is TypeScript?

TypeScript is an open-source programming language developed and maintained by Microsoft to act as a superset of JavaScript for checking types during compilation time. It adds optional static typing to the programming language.

Microsoft has designed TypeScript mainly with large applications in mind such as enterprise applications with over 500 users or more. TypeScript can also be used in back-end apps such as NodeJS for strongly-typed language.

Now let us know when not to use TypeScript at all. Here are some use-cases which you might reconsider the use of TypeScript:

When building small apps or prototypes

I think this is fairly obvious. When you’re building prototypes for presenting the app that you’re building in the market as quickly as possible, you don’t add additional type checkers in your javascript that might hamper your productivity and delivery.

Let us compare the two code when programming some features:

JavaScript

const myFunction = (x, y) => x * y;

TypeScript

const myFunction = <T>(x: T, y: T) => x * y;

Adding TypeScript code in the project requires us to declare types such as this example and you might hate doing that during the prototyping phase.

Notice here that the ones using TypeScript are noisier since we need to declare types to get the job done. Although one could argue that the one using TypeScript is verbose and easy to debug when things get bad for this functionality but that depends on how you or your developer will make use of the type system. Your developer may just simply toss in a lot of any as type in the function so it may not be that helpful at all.

This use-case is debatable though since one might argue that it will save us a lot of time by adding type-checking ahead of time and prevent bugs that might give you some headaches as you build your prototype. It’s true that static types may save you a lot of time in the long run, but not when you’re building your own prototype that might not get to the next stage nor profit it deserves at this point.

Although, in defense of this argument, I believe that TypeScript will only have a little impact at this stage because we’re still building a small app. We rarely have the type issues since JavaScript is built as a dynamic programming language that can parse data regardless of types so it’s very relaxed and forgiving compared to other programming languages.

When it’s not giving any value nor results you expected

TypeScript is only good when it delivers the results it promises but bad if it fails to deliver. You must know first the reason why you want to use and apply it in projects in the first place before actually delving deeper to use it. If it’s not improving your productivity nor the durability of the app you’re building, then you’re not getting much value out of it.

For example, identify first the type of app that you are about to build. Is it a prototype? An enterprise? An API that will be consumed by hundreds of developers? An app that is only focused on User Interactions or Animations? Or an app filled with complex computations and formulas?

You need to evaluate the effectiveness and values TypeScript can offer you first in your use-case then use it so that you can get the most out of it.

When your developers are inexperienced and not willing to adapt in it

You can carefully evaluate and observe how experienced your developers are in using TypeScript. You can also gauge how much learning curve time do they need when they’re going to use it. If you have a bunch of developers who don’t know TypeScript, you might have to back out in enforcing this technology to them unless there’s ROI in doing so.

We cannot always enforce our team to adapt to TypeScript unless there’s a compelling reason to do so and depending on the type of projects your team handles. This also depends on the type of skillsets they have before you enforce it to them. Do they have OOP backgrounds such as C# and Java? If not, this will only cause harm than good.

Lastly, I think it’s worth asking your team whether they’re willing to adapt and use this technology. It could be selfish on your part to just enforce it without gauging your team’s skillsets, proper justification, and analysis of the problem you’re solving.

The need for TypeScript needs to be further analyzed before we delve deeper and use it in your projects with your team and they will thank you for that!

When you’re using it because of “hype”

Last but not least, if you’re just using TypeScript for the sake of “hype”, I think you’re in the wrong direction. For practice and getting the hang of TypeScript, there is no problem in using it. But to use it in production apps just because of “hype” is unreasonable and not a good indicator that this will add value.

Tech hype is a poor metric to measure one’s values of the tools that we’re using. In the case of TypeScript, it has conquered JavaScript ecosystem by storm and widely used by developers these days due to this hype. I think it’s because most developers using TypeScript came from the background of either Java or C# to the point that it was widely used.

I have to admit that I’m one of those developers that jumped right ahead with TypeScript the moment I’ve seen Microsoft releasing it in its early days since I’m not comfortable in using plain JavaScript back in the day.

I’ve been in that situation wherein I jump back and forth in new technologies that I come across. But as I grew more mature as a Software Engineer, I realized that it’s pointless to delve into new technologies or hypes if it fails to provide the value that we offer.

Conclusion

Microsoft gave us this gift to improve developer tooling around JavaScript ecosystem but it could be either a blessing or a curse depending on how we use it.

One takeaway I can give is you just have to learn how JavaScript works and adding TypeScript will act as icing to polish your code further but at the right context with the right use-cases.

I hope I helped you decide when or when not to use TypeScript in your projects based on the use-cases that I outlined above.

Related Stories

Encapsulate components with Bit to run them anywhere across your projects and applications

Bit encapsulates components in your projects with all their files and dependencies, so they can run anywhere across your applications.

Build faster by making your components reusable out-of-the-box, and collaborate as a team to share and discover components. No refactoring or configurations needed, just share components and build truly modular apps.

LEARN MORE

--

--

10% Entrepreneur / Fitness Junkie / Software Engineer / Full-Stack web developer / article writer. Loves reading Philosophy during free time