5 Reasons To Use TypeScript

This post was originally posted on my blog, 5 Reasons To Use TypeScript. Some changes have been made from the original post to fit the styling of dev.to. I recommend reading the post on the original site to see it styled as intended.

The rise of TypeScript seems to have happened slowly, then all at once (like ketchup coming out of the bottle).

Over the past five years, it has continued to grow in popularity until it is now by far the most liked "JavaScript flavour". According to the State of JS 2020 survey, TypeScript is now one of the most used frontend technologies and one with the highest positive opinions.

As I mentioned in my previous post, I was sceptical, but have grown to love TypeScript so that I would recommend it as the default flavour for any new JavaScript project. TypeScript had so many benefits that I hadn't appreciated before I tried it.

In this post, we'll take a look at five of those benefits:

• Compile-Time Errors
• Clearer Code
• Tooling Over Documentation
• Safe Refactoring
• Incredible Autocomplete

1. Compile-Time Errors

Let's get this out of the way first - the obvious benefit to using TypeScript is compile-time errors for type safety.

Did you forget to check if a value is null? Typescript won't.

Missed a case in a switch statement? Typescript won't.

Added an argument to a function but overlooked the existing uses of the function? Typescript won't.

This is generally how people describe TypeScript. It means that, from my experience, when people are hesitant about whether TypeScript is worth the extra effort, this is all they're thinking about.

Compile-time errors are useful, but it's the secondary benefits that you get because of the type checking that makes TypeScript really exciting.

2. Clearer Code

TypeScript requires you to be more explicit with your code and with your mental model of how the code works.

It is said that writing forces you to clarify your thinking. It's so hard to write what's in your head - attempting to write it down forces you to organise your thoughts, challenge your assumptions, question whether there is a better way. TypeScript is the equivalent of frontend development.

Programming is hard. There are huge amounts of complexity. TypeScript restricts the freedom of JavaScript, but by doing so, it reduces the complexity of the code. This makes it a lot easier to catch bugs and move forward with confidence with what we're writing.

TypeScript reduces the complexity of the code. That may surprise you. One of the common complaints against TypeScript is how complicated it is. Sure, the basic use cases may be easy, but pretty soon you're down a rabbit hole with type-generics and conditional types and you're spending more time reading the TypeScript documentation than actually coding.

When this happens to me, 9 times out of 10 that's a flag that my code is too complicated. When I think about what I'm trying to do, I can usually simplify my data structures and function signatures. The advanced parts of TypeScript are positive friction, slowing me down enough to question whether there are better ways of designing my app.

"If you find yourself struggling with writing types or you're basically spending time developing your types instead of developing your app, maybe the code you're writing is too complicated." - Ben Ilegbodu

3. Tooling Over Documentation

Documentation is essential for the long-term health of a project. However, it's also easy to neglect, hard to enforce, and can't report if it is no longer up-to-date. So if it's possible, tooling should be prioritised over documentation.

When I started working at a new company, part of my onboarding involved reading the company's coding style guide. I skimmed through it, but very little stayed in my head. I told myself once I was coding, I would refer back to the style guide to make sure I was following the standards. Unsurprisingly, I never did.

Tools like ESLint and Prettier document your code styles. But they go a step further and enforce those styles while you're coding. You no longer need to worry about stray console.logs or inconsistent semi-colons. Instead of the style guide being one extra thing you have to hold in your head, it becomes something you don't even have to think about. You just focus on what really matters.

TypeScript is a tool that forces you to extract knowledge out of the developer's head and into the code. It documents what arguments a function is expecting, what shape objects are, and which variables may be undefined. And it will remind you when it is no longer up to date and where exactly you need to update.

Without TypeScript, so much redundant time is spent by each developer having to track down the shapes of objects. It requires searching through documentation and praying they are up-to-date. Or it requires debugging the code and praying your guesses of which fields are required/optional are correct.

TypeScript is an up-front investment that saves you and your team much more time in the future.

"TypeScript shines on a team. Even if the team is you and you-from-6-months-ago" - @swizec

4. Safe Refactoring

I recently had two refactoring experiences that were a world apart.

In the first case, I was updating all our buttons to use our common Button component. It was a straightforward change, and completely terrifying. The codebase was JavaScript, there were too many buttons to manually check each one and our test coverage was spotty at best. It felt like I was walking on the edge of a cliff, knowing that if I missed or misspelt a prop, that could potentially stop a button from working - a critical bug.

In another refactor, I was changing the shape of the state. Originally we just needed a list of titles but now we needed a title and a description for each item. Fortunately, this time I was working on a TypeScript codebase so I updated the type from string[] to { description: string; title: string; }[] and then just let TypeScript tell me exactly what would need updating. It was only halfway through that I suddenly realised how hard this could potentially be in JavaScript. Instead, I hardly needed to think at all.

TypeScript not only gives you confidence that you haven't missed anything when you refactor but also shows you where you need to update. You no longer need to manually track your variables all over the code - just follow the red squiggles.

5. Incredible Autocomplete

This section assumes you're using VSCode as your IDE. Both TypeScript and VSCode are developed and maintained by Microsoft so are designed to integrate well with each other.

Other IDEs have TypeScript plugins which also give you Autocomplete. However, I have no experience with using them, so can't comment on how good they are.

The TypeScript autocomplete unexpectedly has become one of the biggest reasons why I love TypeScript. I imagine it's one of the reasons why it's so popular among developers.

Autocomplete means I don't have to worry about typos (did we name this prop color or colour?). I don't have to keep jumping between files to see which component props I need. I don't need to keep googling the names of string and array functions.

Let's say I have a string variable that could be undefined - string | undefined. I want to see if the string, contains a '#' character but I can't remember if I should be using .contains or .includes (happens every time!). I enter the variable name, press . and all the possible string functions are shown to me:

I find the function I want and press tab to select it:

Did you see that? Not only did it help us look up which function we wanted, but it also filled it in for us and used optional chaining to make sure we handle the cases where it's undefined. 🤯

All these mean you don't have to keep interrupting your flow. You can just tab and move on to the next thing. It's like having a co-pilot as you code.

TypeScript As A Default For New Projects

TypeScript isn't perfect. There are plenty of arguments against it (some better than others). But for me, TypeScript should be the default for any new project. Instead of asking if there is a good reason to include it, you should be asking if there is a good reason not to.

Matt Stobbs

@matt_stobbs

#typescript has exploded in popularity over the past few years until it is now one of the most popular JS technologies to use. Despite being sceptical at first, I'm now a TS convert.

Here are 5 reasons why I love TypeScript:

12:43 PM - 28 Oct 2021

Comments

[RRKallan]

nice to have Compile-Time Errors.
But Most of the time data used in JS is dynamic. So cool to have compile error, but what if data has different type as expected. It will throw a error and application isn't useable anymore.

Clear code when using Typescript? I disagree. There readability of code most of the times is very hard

Safe Refactoring
you are changing a type! These type check could also be done with propTypes or Flow. 2 tools which are var way faster then typescript on development time. And Safer there they do the check on run time. So check the console output of your browser

Incredible Autocomplete
Hope this is a joke, there i have full compatibility of auto-completion of JS code

TypeScript As A Default For New Projects
My opinion is a big NO. It woud help on code time. But the ability of bug fixing on runtime is not in scope, and these developers would always point to external excuses. And aren't able to find the problem of the bug without doing a lot of debuggers.
Also Javascript isn't a type programming. Typescript will be translate to Js with out typechecking.
Also to compile in development takes more time.

[Lou Cyx]

but what if data has different type as expected.

Your types should reflect that. If something is coming from an API that can return a number or return nothing, then it should be typed as number | undefined, and you'll deal with that when coding (Using stuff like typeof, ??, ?. and so on).

The readability of code most of the times is very hard

Yes and no. When I write a function, that function might be more complicated:

const vanillaAdd = value1 => value2 => value1 + value2;
// vs
const typedAdd = (value1: number) => (value2: number) => value1 + value2;

But when you use it, you actually get type hints that make it easier:

vanillaAdd("derp")(1); // No errors here, all good!
// vs
typedAdd("derp")(1); // Error in value1 not being a number

And is pretty difficult to reach that scenario because you get suggestions as you type. You can resolve that from JS, but you need to use JSDocs which will make that code as hard (or even harder) to read as TS:

/** @param {number} value1 */
const vanillaAdd =
    value1 =>
    /** @param {number} value2 */
    value2 =>
        value1 + value2;
// vs
const typedAdd = (value1: number) => (value2: number) => value1 + value2;

These type check could also be done with propTypes or Flow

You mean the same propTypes that were removed from the core of React because we have TypeScript and the same Flow that nobody wants to use nowadays? If you rely on propTypes for type checking, the problem is elsewhere for sure.

Hope this is a joke, there i have full compatibility of auto-completion of JS code

It depends. Yes, you get autocompletion of JS but only when the editor can infer the types of stuff or you added the proper JSDocs for that. If you're thinking about libs like react that have autocompletion, I'm sad to inform you that the autocompletion is coming from @types/react, a TypeScript type definition for it. And that applies for a lot of libraries that either use @types/* or they have their own TS definitions.

bug fixing on runtime is not in scope

That's not the work of a type system (not even in typed languages like C++). Runtime testing should be done with unit tests, or even e2e ... not with type systems :/

And JS is a typed system, just because you don't write the types it doesn't mean you don't have them. TS just let you be "explicit" about them. And again, TS compiles to JS and that's what we want. The type checking should be done at compile time, not runtime :/

I agree that TS is not for everything and everyone, but your "reasons" are misinformed at best.

Cheers!

[RRKallan]

const typedAdd = (value1: number) => (value2: number) => value1 + value2;

Will be after transpiling and production ready

const x = (a) => (b) => a + b

So after building a production build all your ts type check will be gone.
And therefore your function will except all kind of types.

You mean the same propTypes that were removed from the core of React because we have TypeScript and the same Flow that nobody wants to use nowadays?

propTypes is removed from the core because the vision of react is that you must be able to configure your dev app as you want and with the most minimum amount of package size.

It depends. Yes, you get autocompletion of JS but only when the editor can infer the types of stuff or you added the proper JSDocs for that.

I had never problems with auto completion with my created libs in JS. And still I doesn’t have
Yes when your lib has a .ds.ts file it will only use the declared and exported for auto completion

And JS is a typed system, just because you don't write the types it doesn't mean you don't have them.

JS isn’t a type program. TS is a superset of JS. To be able to run your code it needs to be transpiled to JS. JS doesn’t care if value changes from type.

Even with unit or e2e test you can’t prevent when api gives you a different type then discribe with TS. Also on production there is no type check. Even on development there is no type check on runtime. In that case you don’t see warning / error on development when running your code and calling an api.

I have enough examples in professional business settings where developers couldn’t find the bug. Because they said testing is succes and no compile errors.
And they said there is no bug. But on production the code was failing and throwing an error

[Lou Cyx]

So after building a production build all your ts type check will be gone.

That's the point, bro. When you use it you have the types, but the browser or node don't need those types, the types are there to help you as a dev, not for the JS interpreter. Type checking is not a UX feature, is a DX feature (is there for us as devs, not for the users).

I had never problems with auto completion with my created libs in JS

You are lucky, then. If you write for example const toHex = value => value. you'll not get autocompletion there because the editor doesn't know that value is of number type, unless you use JSDocs, TS or similar.

JS isn’t a type program.

You really need to read a little more about JS types. JS uses types internally. Just use typeof with a value. The difference with TS is that it makes JS types explicit, while JS types are implicit.

Even with unit or e2e test you can’t prevent when api gives you a different type then discribe with TS

If the API gives you different values, the problem is not with the types, is elsewhere (API architecture, mainly).

TL;DR: I believe you're extremely confused about how types work in TS. The idea with a type system like TS (or Flow) is to help in dev, not in prod. You still need to do type checks in prod when you're not sure about the type of something (like a flaky/unstable API).

[RRKallan]

When you use it you have the types, but the browser or node don't need those types, the types are there to help you as a dev

You mis the point that you still need to code checks to prevent unexpected behaviours and crashing application.

const toHex = (value) => value; i get autocompletion in my editor

You really need to read a little more about JS types. JS uses types internally. Just use typeof with a value.

typeof has a disadvantage see example code

console.log(typeof []); // object
console.log(typeof null); // object

to get the correct type of your value

console.log(Object.prototype.toString.call([]).slice(1, -1).split(" ")[1]. toLowerCase()); // array
console.log(Object.prototype.toString.call(null).slice(1, -1).split(" ")[1]. toLowerCase()); // null

I'm expressing myself wrong, to say JS is not a type program. What i meant JS is a weakly dynamically-typed language and type checks are at runtime and it allows implicit conversion between unrelated types

TypeScript / Python is a strongly typed programming language and type checks are on compile-time and doesn’t allow implicit conversions between unrelated types

example JS

let x = 1 // type is number
x = x + "hello world" // type is string
console.log(x);

example Python

x = 1;   #type assigned as number.
x = x + "hello world";   #type-error, string and number cannot be concatenated.
print(x);

[Lou Cyx]

You mis the point that you still need to code checks to prevent unexpected behaviours and crashing application.

If you type things correctly, and use them correctly, then having the types only at dev time is all you need. If you're using type checking for user facing features, I'm sad to inform you you're doing types wrong (even if you're using prop-types for that). Types are there to help devs, not to do type check of user input. For that you need to write runtime code even in strong typed languages such as C++. Is really concerning that I have to explain this.

I get autocompletion in my editor

That must be an amazing editor if it predicted that value is a number and gives you automcomplete for that ..... unless you're getting autocomplete for all the possible methods of all types in JS, in which case it stops being useful .... when I type that as number wither with JSDocs or TS, I only get autocompletion of the methods of a number. Would you mind sharing what editor are you using and maybe a screen recording of how that autocomplete looks like? I'm not sure we are actually talking about the same quality of autocomplete.

to get the correct type of your value

Actually for Array you only need to do Array.isArray and for null you only need to do === null. My point with typeof is that it shows that JS internally has types.

TypeScript / Python is a strongly typed programming language...

You're wrong again, but I understand, it usually happens when you didn't actually did any real work with TS. Here:

let x = 1; // type is number
x = x + "hello world"; // type changed from number to string (but maybe you didn't wanted that, no way of knowing)

In TS, the only difference is that you need to be explicit about what you want:

// Let's say I want `x` to only have numbers, then the code stays the same:
let x = 1; // type is number
x = x + "hello world"; // type of `x` is still number, so error here because you're trying to assign a string to it.

// But now I want `y` to be either a number o a string:
let y: number | string = 1;
y = y + "hello world"; // No errors here, in the line above I said this is actually what I want.

"But I had to write more" you might reply, and yes, that's right ... but also being clear about your intentions made your code less error prone.

At this point we are going in circles between me telling you types are there just for dev and you insisting in using types for user facing stuff (which is something you shouldn't do anywhere) and creating a straw man out of that, so let's just close it here, shall we?

Cheers!

[RRKallan]

it usually happens when you didn't actually did any real work with TS

It might be wise not to make assumptions. Assuming I haven't actually worked with TS?
Led multiple projects as lead where we use TS

// Let's say I want `x` to only have numbers, then the code stays the same:
let x = 1; // type is number
x = x + "hello world"; // type of `x` is still number, so error here because you're trying to assign a string to it.

// But now I want `y` to be either a number o a string:
let y: number | string = 1;
x = x + "hello world"; // No errors here, in the line above I said this is actually what I want.

the last x will throw an error with TS

My assumption, it needs to be

let y: number | string = 1;
y = y + "hello world"; 

[Lou Cyx]

Some misconceptions here:

1. And?
2. Writing more sometimes makes stuff clearer, ergo, easier to read. The idea with TS is that the "extra code" is there to make your intentions clearer. You don't need to type every single thing, just the minimum and let TS infer the rest.
3. ???
4. JS is a multi-paradigm language, and that includes OOP. You might be one of thoses folks that think that generics/interfaces/classes are OOP, but the truth is OOP is just objects and messages, classes is just one way of achieving encapsulation, but in JS we can use closure, modules and so on. BTW, Tuples are about to be part of JS.
5. This is something that lot of folks say "against" TS, but they don't realize they are basically saying something "against" their architectures and back-ends. If you can't trust whatever is coming from an endpoint, you should type accordingly. This applies to JS as well as TS.
6. Extra dev dependencies, there is a difference there. Extra transpilation will happen either way if you're using TS or not. Almost nobody ships the JS or TS they write directly to the user, they use transpile tools for future features, to be able to import non JS files, etc.
7. Linting and type checking are two different things, and the idea with those is to help you figure out errors before they reach the user (just as tests do).

I agree that TS is not for everything and everyone. You can just use JS with JSDocs if you want. The thing is the items in your list are either outdated or wrong.

Cheers!

[Lou Cyx]

Are we seriously "debating" this?

If an app consumes data that it did not originate [...]

That happens even in C++, let's say you have this code:

#include <iostream>

int main() {
    int input;
    std::cout << "I'm expecting an int, but type a word to make my point clear, please...\n";
    std::cin >> input;
    std::cout << "The value you entered: " << input;
    return 0;
}

If you type, let's say "hello world" and press enter, you get:

I'm expecting an int, but type a word to make my point clear, please...
hello
The value you entered: 0

C++ is a strongly typed language, but when you're facing something unpredictable (like user input, APIs without abstraction layers on top, file system, and so on) you need to test/validate that input, you can't assume that the type will be the one you defined. But no one will tell you that the type system in C++ is unnecessary because of that, in modern IDEs the type system gives you a better DX for the things you control, and for the things you don't, you can have pessimistic typing (basically you type the things you'll expect in the ideal scenario, but also the things that you'll get in the worst scenario), and your DX will still be great.

Now let's use TS as an example, we have an API that responds with this data:

{
    "id": "whatever",
    "username": "example"
}

Someone might code a type for that that looks something like this:

type User = {
    id: string;
    username: string;
}

But that's optimistic. You actually need to type it like this:

type User = {
    id?: string;
    username?: string;
}

This is an oversimplified example, but the idea is that now the type system will make me check if everything is defined before using it, which you might skip accidentally without the types, our even worst you might do in every single place in the app, even when is predictable data. If you don't want to do this by hand, you can use solutions such as io-ts that will do this automatically for you.

To be runtime safe, which is what devs and users want, devs have to write code that is type-aware at runtime, which pretty much nullifies TS.

The idea with TS is to help in dev time, and I said this several times already. At the end of the day is still just JS with JSDocs types embedded on it. If you think that not checking for types at runtime nullifies the usefulness of TS, then you didn't actually understand what the actual usefulness of TS is.

All the other benefits of TS can be had with JSDoc and a good IDE (WebStorm for example gives me autocomplete for virtually everything even without d.ts files).

Even if is kinda funny for me to see "good IDE" and "WebStorm" in the same sentence, I already mentioned that you can achieve something similar to TS with JSDocs. My point was that if you find JSDocs useful but TS isn't, you're almost contradicting yourself, because TS is pretty much just JSDocs as part of the language. WebStorm might infer some things based on context similar to VSCode, but if it doesn't have any kind of hint of what's the type of thing you're coding, the suggestions will be wrong. Once you help the editor a little with type hints such as default values, JSDocs, or TS types, then the suggestions are actually useful because they are based on the actual types.

Every time I see someone complain about TS not checking types at runtime, the only thing I notice is that they completely missed the point, because those same folks see the value on a tool that can transpile their code to different canary features of JS (like Babel), and they also see the value of documenting your code (with JSDocs), but for some reason, they don't see the value of those same things in TS.

I already wrote a lot about this and I feel like a broken record at this point, so yeah, feel free to keep on discouraging the use of TS for the wrong reasons, the rest of us will use that tool when is convenient for the reasons that it's actually convenient for.

Cheers!

[Babak K. Shandiz]

Data validation is a totally different thing than strong typing. The latter ensures your codebase is consistent regarding various data types flowing through it, whereas data validation asserts runtime input compatiblility (of course from outside world, AKA application boundaries) with what the code expects.

While strong-typing is not a must (however makes design/develop a whole lot easier and insightful,) but validation is always required, no matter what programming language or platform you use.

If that helps, as a metaphor, data validation is like the security guard that verifies legitimacy of people entering a military base and makes sure everyone is suited with their formal camo with visible names/ranks, while strong-typing is like the set of military rules that defines the hierarchy and the chain of command.

[RRKallan]

@jfbrennan & @babakks
nice clarifications.

As developer i learned and will teach also defend programming.

@lukeshiru
I strongly advice you to be open for different views. Listen and try to understand the arguments. Try to avoid putting people in a box, saying they didn't actually did any real work, they missing points etc etc. Changing given examples to proof your vision.

[Lou Cyx]

But, the thing is, validations and type checking are two different things. I'm not "putting people in a box", is a fact that you were confusing things :/

I can be open to different views, if those views are correct. Complaining about TS because it doesn't do validations at runtime is not a good reason -_-

[RRKallan]

Good to hear that you don't put people in a "box", and you open for different views :)

From my side, and my assumption of your opinion is as follow.

As i understand your opinion is when using type check, on compile time / development time, is safe enough for your code. And when there is unexpected data coming from example an api, the api needs to deliver as expected.
Based on this it could crash the application because unexpected data. User can't continue and refresh will lead losing data stored with for example Redux.
So my vision is as JS develop you need always be aware and prevent application crash and unexpected behaviours on runtime.

[Lou Cyx]

You didn't understood either my comments nor type checking in TS or in general, but I really said I didn't wanted to waste more time on this conversation. Google is free so, you can google the difference between type checking and type validation. Maybe is a language barrier, but is really not that hard.

[Lou Cyx]

I agree that we shouldn't do "HDD" (Hype driven development), but the thing is we have a "metric" to know when the hype is real or not, and that's the retention. If a tech is driven by hype but actually sucks, then the bounce rate is high, but the thing is "once you go TS, you never go back", even projects like svelte that removed TS, are still using it in a way (they moved to JSDocs and use TS to check for the types). And again...

JS has is prototypal based and although multi paradigm is still not on par with Java or C#

You don't need classes, interfaces and all that jazz to have OOP. OOP is just objects (encapsulation) and messages (data transfer between those objects). You can do OOP or FP with ease in JS, you don't even need inheritance (a really poor reuse/extension mechanism, compared to composition), so you don't even need to use prototype to have OOP. It's a really common misconception:

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
~ Alan Kay (the guy that popularized OOP)

No mention of classes, inheritance, and so on.

[Rammina]

Thank you for sharing your insights about Typescript!
While I do agree with the majority of your points, here are some downsides that make me not use it sometimes.

[Lou Cyx]

"the fact that TS does type validation at dev instead of runtime negates TS" ... if you really think that a type system that doesn't do validations for you is not useful, I don't have anything else to tell you. I already explained that type checking in dev is extremely useful and allows you to detect some issues way before you go through your validations, but whatever... Google is free...

[RRKallan]

No need to tell me the difference, ether i don't need to google to get now about the differences. And this is exactly a point which i mentioned on my previous comment and is not the first time you do this, not only on me.

As previous said, where my feeling is you are ignoring it, i'm working with TS on my projects, Im up to date and now how to use. On these projects i'm the lead.

The fact is you don't care about runtime behaviour.
In your opinion you have a perfect code with type check on compile / development time.

All unexpected behaviour on runtime is a problem from outside.
Even when your application crash you will point out to external facts, and not your problem.
And i can bet you won't be able to find the bug, or you will need a couple of days to figure out the problem.

[Lou Cyx]

"You don't care about runtime behavior" ... You see, you didn't read what I wrote at all. Why keep this going if you aren't reading at all? I said that validations and type checking are two different things, not that one matters more than the other ... but whatever... I really don't want to keep dealing with your straw man

[RRKallan]

You see, you didn't read what I wrote at all

And again making a wrong assumption. I read your comments.

If the API gives you different values, the problem is not with the types, is elsewhere (API architecture, mainly).

my comment

TypeScript / Python is a strongly typed programming language and type checks are on compile-time and doesn’t allow implicit conversions between unrelated types

your reaction

You're wrong again, but I understand, it usually happens when you didn't actually did any real work with TS.

one of the first things on typescriptlang.org

TypeScript is a strongly typed programming language that builds on JavaScript

and so we can go on.
I notice already you are avoiding given points.
I wish you luck on a national / international big brand, own JS package national / international used.