loading...
Cover image for Why use static types in JavaScript? (Part 3)

Why use static types in JavaScript? (Part 3)

iampeekay profile image Preethi Kasireddy ・3 min read

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!

Discussion

pic
Editor guide
Collapse
millebi profile image
Bill Miller

In non-trivial coding, type checking will always produce less idiotic buggy code (i.e. The bugs that are PEBKAC's) and will also reduce the number of "stupid" tests (Null/undefined failures, detect garbage input, etc...). So in almost all cases, having a compiler complain that you have a type wrong will help you in the long run.

Your point about it complicating the learning curve, is somewhat valid, but for most beginners it forces them to think and remember what they were actually attempting to create in a more clear and concise manner. Having to decide that you're creating a function that calculates a set of areas based on radii ensures that you don't bastardize the function to do something else in a convoluted manner. This is a core programming task of breaking down the problem into smaller well defined pieces that can do one thing well and not 10 things badly. Not learning this results in sloppy and horrible code. The extra time it forces on the beginner always pays off in the future (even when it's a real pain at the time).

It's like driving a car: If you aren't taught by someone that is very stringent in how you do things, you end up being a menace on the road and potentially kill other people because of sloppyness/uncaring.

(Forgot to mention: Great articles, they should trigger some interesting discussions in many developer groups)