Firstly let’s gets some of the misconceptions out the way. I so often hear people talk badly about Typescript. When I ask these trash-talking folk what they have used Typescript for, the usual response amounts to them explaining that they built a “Hello World” app once and read the first paragraph of the docs.

Hello Worlders are entitled to their opinion but I’m a firm believer in you get out what you put in. If you approach Typescript with prejudice and don’t put the effort in to learn you aren’t going to like it.

Typescript is a static type analysis tool, we shouldn’t carelessly compare it to Babel.
Typescript is a superset of Javascript, we can’t blame Typescript for problems that exist in vanilla Javascript. 
Typescript’s approach to classes isn’t bad, classes themselves are bad — come at me functional programming naysayers.

With that out of the way let’s dive into a few of the love-hate aspects of Typescript.

😍 Refactoring just got a whole lot easier

One of the aspects of Typescript that becomes immediately apparent if you use it for any period is that refactor just got a whole lot easier. This is especially obvious when it comes to re-architecting your code. You can move blocks of code and components around and have confidence that you haven’t broken any of the props or APIs. If you have the compiler and hopefully your IDE will light up like a Christmas tree.

🤯 Index types ruin inference

Initially, index types seem like a great idea. They give you neat ways of defining objects with a common type for example: 

{ [key: string]: boolean }

However the difficulty comes when any gets involved. Often, to make types more flexible (which is a weird idea in itself) You will see something like this: { [key: string]: any } (This is common place in third party libraries). This causes all sorts of problems with typescripts ability to infer types. Take the following example:

interface Person { [key: string]: string, name: "string" };
const person: Person = { name: "Jake", lastName: "ford" };
person.lastName // perfectly happy with this

const other = { address: "street" };
const mergedPerson = { …object, …merge };
mergedPerson.lastName // this will cause a type error;

We’ve defined two objects. The first one has an index type of string which allows us to define an object with two properties name and lastName. Later when we merge this with other. For some reason, typescript forgets about the lastName property. When we do a lookup of mergedPerson.lastName it will tell us lastName doesn’t exist.

😍 Code is easier to understand

One of the arguments used against typescript is it makes your code more verbose and adds more overhead because you have to spend time defining interfaces and types. While this is true, I don’t know why we are considering this a bad thing. Let’s face it, we already don’t do enough to comment our code. Typescript adds an element of self-documentation to our code. By its dictionary definition an interface is defined as 

a connection between two pieces of electronic equipment, or between a person and a computer.

Typescript interfaces help describe these connections.

🤯 Any is bad by design

any has been implemented in Typescript as an opt-out solution. If you don’t want your code to respect any specific type then type it as any. Seems like a fair idea? Wrong. any is the single point of failure for any project using typescript. Take the following example:

const number: any = 1;
const array = [10, number];  
const fubar = array[0];

I’ve defined a number as any. I then include it in an array with another number. What I have is an array of numbers but because I’ve mixed in any Typescript types it as an array of any. So now if I pull out one of the values from this array its type is gone and is instead any

This is a trivial example but it represents a very real problem with having any in typescript. The whole idea that you can mix untyped stuff with typed stuff is flawed.

🤯 False confidence about what you are writing

This brings me to my final point. Typescript offers a unique and wonderful set of tools for building things with Javascript. However, because of the above-mentioned reasons can you ever really trust typescript to type things correctly? And if we can’t trust it is there really any reason to use it in the first place? 

I don’t know the answer to that question. I do know that I will continue to use typescript and will suggest it’s usage over javascript in most cases. I feel the overhead it introduces is worth it to have a typed (even if it’s loosely) project.

I think the future of the web is looking really bright. With the introduction of WebAssembly (which I'm starting to have so much fun with!) and the ability to write web applications in properly typed languages such as C, C# and Rust etc it's an exciting time to be building web apps!

I hope you enjoyed this article if you have any opinions or feedback fire me a message on LinkedIn!

Note: there are a million different rules you can set up for typescript that can mitigate some of these issues but good luck getting buy-in on your typescript project to make the types any more strict than how they come out the box.