About Me: I've been a professional web developer for just over 10 years now. I'm currently the lead web development instructor at Better Coding Academy, and as part of what I do, I post videos on our YouTube channel at https://www.youtube.com/c/BetterCodingAcademy.

(Subscribe for awesome web development content!)

Six months ago, I made this post on Dev: TypeScript is a waste of time. Change my mind.

To my delight, the comments section became an amicable yet passionate discussion on the temporal economy of the typed language.

It has been six months. I have written over 10000 lines of TypeScript code in a production environment, and I am now writing this article as a follow-up to the thoughts I expressed in my original post.

I've now written over 40000 lines of Flow code and over 10000 lines of TypeScript code for various production environments. I'm by no means a perfect developer, and even though I've been coding for 10 years now (cries in existential crisis) I like to believe I am intellectually flexible enough to change my mind upon receiving new evidence.

Okay, so how exactly has your opinion changed?

I made four main points in my original article:

The pros aren't really pros.
Typed JS is long and difficult to read.
Typed JS is still... untyped.
What's so bad about untyped JS?

I no longer agree with all four of these points, and I'll share what I've learned regarding each of them below.

The pros aren't really pros.

At the time of writing the article, I felt that a large number of TypeScript evangelists would make an appeal to authority (namely large companies) for compelling reasons as to why you should use TypeScript.

In response to this, in my previous article I wrote:

However, if you honestly think about it, this argument falls apart reductio ad absurdum:

Big companies use TypeScript, therefore I should use TypeScript.

Big companies also use legacy systems, therefore I should use legacy systems.

Although I do not retract this statement, I have come to understand that there are some "pros that are really pros" when it comes to using TypeScript over Vanilla JavaScript. Let me explain.

Typed JS is long and difficult to read.

I used the following example in my original article. This is the untyped version of the code:

import React from 'react';
import ApolloClient from 'apollo-client';

let apolloContext;

export function getApolloContext() {
  if (!apolloContext) {
    apolloContext = React.createContext({});
  }
  return apolloContext;
}

export function resetApolloContext() {
  apolloContext = React.createContext({});
}

And this is the equivalent version in TypeScript:

import React from 'react';
import ApolloClient from 'apollo-client';

export interface ApolloContextValue {
  client?: ApolloClient<object>;
  renderPromises?: Record<any, any>;
}

let apolloContext: React.Context<ApolloContextValue>;

export function getApolloContext() {
  if (!apolloContext) {
    apolloContext = React.createContext<ApolloContextValue>({});
  }
  return apolloContext;
}

export function resetApolloContext() {
  apolloContext = React.createContext<ApolloContextValue>({});
}

With respect to this code, I said:

I genuinely don't find them more readable in most cases.

However, I've changed my mind on this part. After seeing the syntax each day for a couple months on end I've become quite accustomed to it. Additionally, I have learned to appreciate the benefits that this syntax provides over its untyped counterpart.

Typed JS is still... untyped.

because TypeScript compiles down into JavaScript, regardless of how carefully designed your types are, there always is the chance that a different value type sneaks into a JavaScript variable. It's unavoidable - JavaScript is still untyped.

I've changed my mind on this part as well. Admittedly, there is the chance that an unexpected value of any type "sneaks" into somewhere you don't want it to go. However, that doesn't mean that static type checking is completely redundant.

It's like saying: because there's a (very) small possibility I'll injure myself, that means I should never do any form of weight training, or exercise for that matter.

It feels strangely hypocritical correcting myself, but I'll continue on.

What's so bad about untyped JS?

If there is hard statistical data that using untyped JavaScript vs. TypeScript means that productivity decreases by any significant amount (if at all), then I wouldn't mind the verbosity of TypeScript.

...and this is where I am yet to see that data.

Admittedly it's a lot to ask for, and I don't expect such evidence to (ever) become readily available.

However, regardless of whether we have such statistical data or not, I still believe that untyped JavaScript "isn't bad". In fact, I'll probably be sticking to Vanilla JavaScript for the majority of production projects from now on, and here's why.

Wait, so you're not using TypeScript anymore?

Nope. I used it for a couple months, and got into the serious nitty-gritty, from writing custom type declarations, to using union types, to using nested generics and more. It definitely was not a "light" usage.

However, I've decided to stick with Vanilla JavaScript for future production projects.

There are a few issues I uncovered when working with TypeScript that I still consider unbearable given my present circumstances:

TypeScript is not well-documented.

I'd absolutely love to be proven wrong on this one here.

Sure, there's plenty of documentation when it comes to typing your number variable or your simple function, but what about, for example, a higher order function that creates another function which manipulates an object you pass into it in a certain way? I'm sure it's possible to type such a function using generics and whatnot, but I've many times been unable to figure out how via the official TypeScript docs.

Oftentimes I'll run into some sort of TypeScript issue. Perhaps it's caused by my code, perhaps my configuration, or perhaps it's legitimately a bug in TypeScript. Where a similar issue in, say, React, can be easily resolved through online searches within a couple minutes, I find myself constantly spending more than one hour on each of these concerns, and this leads me perfectly into my next point.

I still need to write code, faster.

Since adopting TypeScript, I've noticed a substantial decrease in my rate of feature production. Which makes sense - I'm literally writing more code to get the same feature done.

Oftentimes I have hardly any wiggle room on project deadlines.

Oftentimes my priority is to ensure a feature is well-tested and production-ready as soon as possible - and to me that means using various types of testing to increase my confidence in the code.

Unfortunately, this means that oftentimes my priority is not having self-documenting, statically typed code.

This is a sobering reality I face. If you are not constrained by these deadlines (maybe you work in corporate? :P) then perhaps TypeScript will work just fine for you. However to the rest of you out there, I want you to know that TypeScript will take more time. It absolutely will. But it's up to you to decide whether that extra time is worth it.

Thank you for reading!

To those of you who took the time to read through my article, thank you! I really hope that my content has been insightful.

I post videos on on YouTube at https://www.youtube.com/c/BetterCodingAcademy, featuring tutorials on various tech buzzwords such as React, Node.js, TypeScript, GraphQL, Microservies, Docker, and more. :)

As always, I come from a place of love and humility, and I would greatly appreciate it if you left non-scathing discussion or criticism in the comments. I would love to learn more about this and have my viewpoint shaped as well.

Happy coding!