TypeScript? More like HypeScript to me.

This is not to say that I don’t want to use TypeScript. Please keep in mind that I’m only highlighting a bunch of serious disadvantages in my eyes.

Without further ado…

1. “Gradual adoption” is a lie

One of the selling points of TypeScript was gradual adoption. Instead of “all or nothing” you can adapt TypeScript step by step, for example, one file or one directory at a time. I’ve always thought that kind of adoption to be superior.

Yet in reality… I have never seen a project where this was the case. I have never seen a developer who ever considered that. TypeScript as such seems too greedy for such gradual adoption – config is much more complex… Writing vanilla JS + a bit of TS doesn’t seem to be an option.

Sidenote: the same happened to React. It used to be a tool designed to be adopted gradually. Fast forward 5 years, it’s the whole ecosystem. Adding React to a few DOM leafs is no longer an option. Go to any React developer and ask if they ever considered gradual adoption. Nowadays you have to write React applications, including things like routing, that doesn’t suit there.

2. Makes devs lazy in terms of testing

So yeah, we have TypeScript. We don’t have to test if the type returned is correct, TS does it for us. So what else to test?

…

…

I don’t know. Do we have to test anything else?

Yes, you have to. Let me tell you that – type-checking tests are stupid. With a good test base can be entirely avoided, regardless if you have types or not. Well written tests test behavior, not implementation.

Using TypeScript doesn’t mean you can write fewer tests.

Of course, tests and type checking are not strictly equivalent. But in practice, I feel people are too reliant on type-checking, and therefore too relaxed in other types of checks.

3. Inconsistent syntax

You define type as a regular JS object (you can omit commas, though):

type DBRecord = {
  user_id: string,
  username: string,
  gender: string,
  year_of_birth: number,
  phone_number: string
}

Cool, very handy to remember!

On the other hand, the interface definition is missing the equal sign:

interface Comment {
  id: number,
  score: number,
  content: string,
  createdAt: string,
  createdBy: string,
  cardId: number
}

Why? Because it would make too much sense, I guess.

(again, commas are optional)

Enums, however, are just like interface, except their values are after the equal sign (instead of colon):

enum VotedStatus {
  NoVote = 'no-vote',
  Upvote = 'up-vote',
  Downvote = 'down-vote'
}

And forget about omitting commas 😂.

4. Lack of conventions

Look at the TypeScript options. Two configurations stand out to me:

  • noImplicitAny
  • strictNullChecks

Depending on which option you choose, TS is a completely different tool in terms of developer friendliness. Why it matters?

Configurability like that means that TypeScript can be in fact many different tools. It is possible that, when talking about “TypeScript”, we are talking about entirely different things! One can boast TyeScript in one configuration, the other can complain about TypeScript in other configuration. They can agree to each other, even though it looks like they have very opposite opinions on the same subject.

This has to lead to misunderstandings.

The solution is conventions, however, in my experience, there are no good conventions in teams.

This may be related to a fact that TS is relatively fresh technology, and good conventions come with maturity. TypeScript, therefore, is not yet mature enough to me for wide adoption.

5. Silly error messages

source

Cool, TypeScript, thanks a lot!

6. Discourages from refactoring

The amount of code (types, interfaces, new files, and imports) you have to be writing is huge. This concretes the implementation and effectively discourages from refactoring.

If I’m about to introduce a new idea that I’m not even sure if it works – then I need to write interface, type, and whatnot. I’m more likely to just say “f**k it” and the project has just missed a great opportunity to increase its quality.

7. It’s too costly

I’ve always judged technologies in terms of the balance of profits and losses. Of course, each technology has its benefits, but also comes with the cost. Does the cost outweigh the benefits? Will the technology be “net positive” in my projects?

I’m not saying TS doesn’t give you benefits. I understand and appreciate it. However, I’m saying that it’s not worth it.

In the previous chapter, I wrote that TS makes you write much more code. But it’s not only that. Because some things are given name, you’re having additional headaches about naming convention.

If you’re like me, you like simple rules and consistency. Introducing TypeScript makes you think about dozens of new names.

Again the “gradual adoption myth” comes into play. If it was just in files that I want it to be, I could live with that. But given apparently your entire project has to have TypeScript, I’d say it’s too much of a cost.

Summary

If you want your tool used widely, make them easy to use. “Easy to use” means to me little code & consistent (predictable) API. TypeScript has neither 😔.

Perhaps some of the downsides I noted aren’t TypeScript’s fault per se, but rather how people turned out to use this tool. Doesn’t matter to me. As I tried to highlight in the latest point – technology should be judged with its costs, and people’s understanding is one of them.