TypeScript vs JavaScript: a chief software engineer’s perspective

Every time I hear questions like “Why is TypeScript better than JavaScript?” or “When should we use JavaScript instead of TypeScript?” I stop and think — why is one better than the other? Is one a panacea? Should we use it in all cases?

Let’s dig a bit deeper, check out the top five reasons to use TS vs JS, and then analyze when it’s better to use pure JS.

#1. A superset of JS

“Superset” is a fancy and somewhat overused term in this context. Even though it’s part of the marketing campaign, in general it means that TS is JS plus more features.

The most significant difference between TypeScript and JavaScript is that TS includes primitive types, the opportunity to create custom types, mapped/conditional/template literal/utility types, abstract classes, interfaces, generics, Enums, and so on. This incredibly long list also includes some language-specific features such as decorators, mixins, and namespaces.

While amazing, all of this increases the TS learning curve drastically. Beginners, especially those who have never dealt with strongly typed languages, might struggle to learn all of its functionalities. On the other hand, designing in types can save a lot of time and make you think more broadly, even in pure JS.

#2. A better developer experience

This advantage logically flows from the previous one. TypeScript is highly integrated with IDEs. You can easily browse your code, find the entry point of the data, and learn what properties any object consists of.

Your team members will understand the data flow more efficiently, which leads to better code quality, easier refactoring and design.

In addition, TS prevents bugs (not all of them, since some mistakes such as logical or runtime errors cannot be caught) and has a flexible configuration.

Last, but not least, TS is compatible with a ton of npm packages and you can easily download typing files. Everything will work out of the box, though some packages might not have typing and you will have to declare them on your own.

A potential problem here is that TS can give you a false sense of security, so you will need to use other tools for maintaining code quality and code reviews.

Useful reading: Creating Types from Types

#3. Easy start and adoption

To start working with TS, you need to install a compiler, define configuration in the tsconfig file, and plugin for your IDE. Infrastructure-wise, that’s it.

In most cases TS is usable out of the box, and comes with popular frameworks (Angular, Nest, and so on). For existing projects, it’s possible to introduce TS incrementally because of its compiling nature, so there will be no need to rewrite the whole code.

As I mentioned before, it’s not always easy for beginners to start using TS. But it’s on par with most typed languages, so it’s way simpler to learn for developers who already have prior experience with strict typed languages. And of course, TS is a blessing for OOP aficionados.

Useful reading: What is a tsconfig.json

#4. A strong global community

TypeScript is a part of the Microsoft ecosystem and it gains more popularity by the day. The demand for TypeScript developer jobs is also steadily growing.

It’s widely used by top tech companies such as Google, Airbnb, Shopify, and Adobe, so we can assume that it meets their requirements in terms of codebase scalability.

TypeScript also has a lot of amazing open source contributors, documentation, and tutorials. It’s near the top of the list in many ratings such as Stack Overflow Trends and TIOBE Index. A range of self-study materials and boilerplates are available across the internet.

Useful reading: The TypeScript Handbook

#5. Versatile compatibility and compilation capabilities

As I said, TypeScript is a superset of JS, which means it compiles to pure JavaScript and thus can be run everywhere.

It can be used on both the frontend and backend (with Node.js) of an application — everywhere JS can be used.

Moreover, the advantage of TypeScript over JavaScript is that it’s backward compatible and can be compiled to any ES version, including ES7, ES6, ES5, and even ES3.

By now you might be convinced that TS is incredible and should be used everywhere. I can’t agree with that, however, and I’ll explain why.

In my experience, there are several cases when TypeScript is not appropriate:

When you want to use TS for its own sake

You shouldn’t use TS if deadlines are tight, or you’re developing a PoC that should be delivered fast and then thrown away. In other words, when it’s overkill. Such cases are notoriously full of the implicit usage of “any” and @ts-ignore all over an app.

When you deal with highly dynamic data

A friend of mine is working on a project in which it’s nearly impossible to figure out the type of incoming data, since it’s related to the downstream services of their clients. TS is not ideal in this situation.

When you don’t want to compile the code

It’s a rare situation but I need to mention it anyway.

Since TS is being compiled to JS, the size of the outcome might be bigger. Additionally, on pure JS, developers can control the code performance better.

When your team is not ready for TS

Again, sometimes the learning curve matters. When no one in your team has any experience with TS, it’s better to start with JS and then migrate to TS later, to improve the delivery process.

Useful reading: Migrating from JavaScript

So, let’s all agree that TypeScript is not a silver bullet. It’s just another tool in our toolbox, so let’s use it wisely.

Personally, I really like TS, but the benefits depend on when, where, and how you deal with it.

For instance, the usual problem we face is overtyping, when the types are being created seemingly whenever you sneeze or when we change the types, and we need to adjust them all over the application.

The key is to weigh your pros and cons before adding another tool (in this case TS) to your application.