Why use static types in JavaScript? (Part 3)

Disadvantages of using static types

Like anything else in life and programming, static type checking comes with its tradeoffs.

It's important that we understand and acknowledge them so we can make an informed decision of when static types make sense and when they simply aren't worth it.

Here are a few of those considerations:

1. Static types require investment upfront to learn

One reason JavaScript is such a fantastic language for beginners is because it doesn't require the student to learn an entire type system before they can be productive in the language.

When I initially learned Elm (a statically-typed functional language), the types often got in the way. I would constantly run into compiler errors related to my type definitions.

Learning how to use the type system effectively has been half the battle in learning the language itself. As a result, static types made the learning curve for Elm steeper than for JavaScript.

This matters especially for beginners where the cognitive load of learning syntax is at an all time high. Adding types to the mix can overwhelm a beginner.

2. Verbosity can bog you down

Static types often make programs look more verbose and cluttered.

For example, instead of:

async function amountExceedsPurchaseLimit(amount, getPurchaseLimit){
  var limit = await getPurchaseLimit();

  return limit > amount;
}

We'd have to write:

async function amountExceedsPurchaseLimit(
  amount: number,
  getPurchaseLimit: () => Promise<number>
): Promise<boolean> {
  var limit = await getPurchaseLimit();

  return limit > amount;
}

And instead of:

var user = {
  id: 123456,
  name: 'Preethi',
  city: 'San Francisco',
};

We'd have to write:

type User = {
  id: number,
  name: string,
  city: string,
};

var user: User = {
  id: 123456,
  name: 'Preethi',
  city: 'San Francisco',
};

Obviously, this can add extra lines of code. But there are a couple arguments against this being a real downside.

Firstly, as we mentioned earlier, static types help eliminate an entire category of tests. Some developers would consider this a perfectly reasonable tradeoff.

Secondly, as we saw earlier, static types can sometimes eliminate the convoluted error handling and in turn reduce the visual clutter of code significantly.

It's hard to say whether verbosity is a real argument against types, but it's one worth keeping in mind.

3. Types take time to master

It takes time and lots of practice to learn how best to specify types in a program. Moreover, developing a good sense for what is worth tracking statically and what to keep dynamic also requires careful thought, practice, and experience.

For example, one approach we might take is to encode critical business logic with types, while leaving short-lived or unimportant pieces of logic dynamic to avoid needless complexity.

This distinction can be tough to make, especially when developers less experienced with types are making judgment calls on the fly.

4. Static types can hold up rapid development

As I mentioned earlier, types tripped me up a bit when I was learning Elm — particularly when adding code or making changes. Constantly being distracted by compiler errors made it difficult to feel like I was making any progress.

The argument here is that static type checking might cause a programmer to lose focus too often — and as we know, focus is key for writing good programs.

Not only that, but static type checkers aren't always perfect. Sometimes you run into situations where you know what you need to do and the type checking just gets in the way.

I'm sure there are other tradeoffs I'm missing, but these were the big ones for me.

Up next, Part 4 (coming soon)

In the final section, we'll conclude with discussing if and when it makes sense to use static types. Stay tuned!