Static Type Checking vs Dynamic Type Checking in JavaScript

November 14, 2019 0 Comments

Static Type Checking vs Dynamic Type Checking in JavaScript



Fernando Doglio
Image by PublicDomainPictures from Pixabay

Do you prefer discovering bugs during execution time or during the bundling (or any other stage you have before publishing your code)? Would you rather let the code figure out your data types or do you prefer leaving clues about them for other tools to perform the checks for you?

This is not about right vs wrong or having a sure way to always perform type checking correctly. In fact, it’s all about circumstances and personal preferences.

Let me explain: Type Checking takes care of making sure you’re using the data as expected. In other words, it’ll help you check you’re not using a number like a string, or that you’re not trying to subtract 42 from the word “cat”. These examples might sound crazy, but for a loosely typed language, such as JavaScript, they are, not only possible but likely to happen.

Whatever the case is, in this article I’m will be covering what both methods of performing type checking are and how you can achieve them in JavaScript.

Tip: When sharing reusable JS components using tools like Bit (Github) — use type-checking. It will make your shared components more developer-friendly and less prone to errors.

Example: A React component with type-checking, shared on

Static Type Checking in JavaScript

This type of type-checking is performed before execution, it can happen during compilation (if you’re working with a compiled language) or during the bundling stage (if you’re working with a scripting language). Considering that this is another form of code-verification, performing it whenever you do your unit tests is a good idea.

That being said, the concept of static type checking for JavaScript is “unnatural”, since by definition, the language is weakly typed (or dynamically typed, depending on which definition you want to go with). So performing type checking on JavaScript means dealing with the following facts:

  • The language has types attached to values
  • Operations with those values react in different ways depending on their types (i.e you can divide 2 by “hello”, and you’ll get NaN, while 2 divided by 2 would yield a number).
  • Variables don’t have a type, so you can use the same variable to store a string value, then assign it a number and it’ll still be valid code and it will execute correctly.

With this in mind, the following code would be perfectly valid in JavaScript:

Reading the above code, what would you say is the type of x or the return type of fn? Really, you can’t tell, and the language will even try its best to accommodate for some strange, unforeseen use cases, such as:

fn("hello") => "hello1"
fn(_ => 3) => "_ => 31"
fn({prop:1}) => "[object Object]1"

With that in mind I think I’ve answered the following question:

Why would you go through the trouble of adding static type checking into a language that was designed to work without it?

Clearly, trying to avoid scenarios like the ones described above is a very common answer.

Others might include:

  • Code becomes less error-prone since you have an extra layer of verification on top of your code that catches simple (yet very common) mistakes.
  • Potential for code optimization, if your compiler (and I’m using that word lightly here, but you can think of transpilers as well) can pick up on better ways to write some sentences based on the types you’re using.
  • Your code is easier to read by others. Not having to mentally parse types is a great help for developers trying to understand code from others.
  • Support for better tooling. With static type declarations, your IDEs can help you write better code by making suggestions or performing checks while you write.

I’m sure you can also add some more things to that list, and that alone shows how much potential a static type checker for JavaScript has, so what are our options?

Existing Static Type Checkers for JavaScript

Although the idea (and the added benefits) of having a static type checker for this language might sound so compelling, the actual effort required to do so seems to have hindered most efforts.

Therefore, there are two really useful options out there: Flow and TypeScript.

Using Flow

Flow allows you to add type annotations to your Vanilla JavaScript and then process that code to check for problems.

You can install it with npm writing:

$ npm install --save-dev flow-bin

And then installing its type-remover (since you’ll need to strip away the added annotations for your code to be correctly interpreted):

$ npm install --save-dev flow-remove-types

You’ll also need to add a few script to the package.json file of your project:

That is, of course, assuming your code is inside the src folder and that you want the final version (the “compiled” JS code,if you will) to be stored inside the lib folder.

You can then start annotating your code like this (notice the first line, without it, Flow will ignore your files, so don’t forget about it!):

Later, if you were to test your code with Flow, you’d get something like this:

Of course, given that the + operator works for both, strings and numbers, without the annotations, your code would work. This merely ensures you get the results you’d expect from an actual concat function.

You can read all about their annotations here, if you want to know more about them.

Another cool and interesting bit about Flow, is that in some cases, it is capable of inferring expected types without you having to specify them. For example:

The above code would fail, because it knows you’re not supposed to use the * operator with strings!

Using TypeScript for your type checking needs

While Flow allows you to add type annotations which you later need to remove, TypeScript is actually a whole different language built on-top of JavaScript. It provides you with the ability to perform static type checking, which is why I’ve added it here, but it also provides a lot more, so you should check it out if you haven’t yet.

Because of the nature of the language, you’ll have to install a transpiler, which will translate your TypeScript code into JavaScript once you’re ready to test it.

You can do that with npm with the following line:

$ npm install -g typescript

To check your code and transpile it, you’ll use the following line:

tcs your-file.ts

Notice the .ts extension, that’s how you tell TypeScript which files to analyze. There is no need to add extra comments in your code like with Flow.

Using the same example we used for Flow (minus the first line), you’ll get this output from TypeScript:

Although it’s a bit less verbose, it provides you with the same type of error Flow did.

However, TypeScript will not try to infer types if you don’t specify them, so the second example, with the square function will not throw an error here. In other words, if you’re choosing TypeScript, you’ll need to be mindful about the type declarations, otherwise you won’t get the best value out of it.

Is it worth it though?

Before we move on to dynamic typing, I think it’s important to acknowledge the extra effort required to add static type checks into a JavaScript source code. Because it’s not just about using the right tool, the language itself does not support it, so there is no workaround here, you’ll need to write a different version of JavaScript and then you’ll have to transpile it in order to execute it.

It adds (at least) one step to your build process, it also requires you to write more code, which if you think about it, goes against one of the main benefits of using JavaScript for web development: less code to write means faster time to market.

This is not to say static type checkers aren’t worth your effort, you just need to make sure it’s the right decision for your current circumstances.

Dynamic Type Checking with JavaScript

Static type checking is great for helping you keep your code more structured and to avoid simple bugs, but once you start depending on outside sources for your data (i.e reading data from a JSON file someone else wrote, getting input from a web form, and so no), you can’t really rely on static checks. Those sources will affect your code during execution, so it’s impossible to know if everything will work before then.

Which is why, you have dynamic type checking. Right on the other side of the spectrum, this particular brand of checking is meant to happen during execution time instead of beforehand.

And it might not have been obvious if you weren’t paying attention, since the duck-typing nature of JavaScript allows for a level of mutability that makes it very easy to assume there are no types. After all, the following code just works:

But there is! There is dynamic type checking, and you can see that when you try to add two variables. The result of that operation will have very different outcomes depending on the type of their values (i.e it’s not the same to add two strings than two numbers, or a string and a number).

And just to be clear: if you’re still thinking that the above behavior means “no types”, the actual result for a no-types system would be for the language to interpret all values in the same way, taking into account their numeric representation (after all, that’s what they are to the computer). So adding two strings, would result in a numeric value representing the addition of the bytes that comprise those strings. You could potentially later re-create a new string from that number, but of course, it wouldn’t be the concatenation you’d expect.

Is it worth it, though?

The upside to this type of checking, however, is that there are no tools required to have it available in your projects. After all, JavaScript was built with it in mind.

Of course, there are other benefits to these types of systems, such as:

  • Faster development type. Since devs don’t have to worry about carefully planning their types and the code to handle them, writing logic becomes a much natural task.
  • Easier-to-read code, as long as the developer builds it with readability in mind. Using the proper techniques you can write code that reads very naturally without having to go through 10 lines of types definition.

One could also argue that there is a downside to this approach as well, and just like with everything, it would be true. After all:

  • Careless or inexperienced developers are more prone to adding errors to their logic. These errors should be found during the testing stage, but alas, we’re not covering tests in this article.
  • Having the engine perform these types of checks during execution can take a toll on performance, after all, optimizing code that you can’t trust is not an easy thing to do (not to say there aren’t ways, they’re just harder to implement!).
  • Finally, a common problem you see with tooling surrounding dynamically typed languages, such as JavaScript, is their lack of proper help. It’s very hard to create an IDE that provides the level of intellisense (just to name a single feature here) for JavaScript that Eclipse provides for JAVA for example. It would be amazing if Sublime or even VS Code would do that, but unless you force that extra level of definition into your code (by specially formatted comments, for example), there is nothing they can do about it other than provide basic auto-complete.

We could go on further, but you get the point.


In the end, there is no correct way of approaching this topic. It all depends, as I’ve already stated, in your particular circumstances and your (and probably, your team’s) preferences when it comes to writing code.

Are you happy with the way JavaScript behaves in regards to type-safetly? Then by all means, ignore static type checking, and just be careful to add the required processes around your team to help them avoid common mistakes.

Are you the type of developer who’d rather write a few extra lines to code to make sure everything works as expected? That all is well and structured? Then by all means, give Flow or TypeScript a try, you’ll most likely end up loving them!

Either way, just remember that they’re both very viable ways of working and there is no write answer, just two different sides of the same JavaScript-powered coin.

Leave a comment below if you’d like to share with the rest of the class which one is your favorite and why!

Otherwise, see you on the next one!

Learn More

Tag cloud