Love it or hate it, Javascript is the most popular programming language in the world. If you find a software engineer, I can almost guarantee that they’ve, at the very least, made some reasonably sized applications using Javascript. Stack Overflow’s annual survey has Javascript as the most used language for the last 10 years. For anything to be at the top for so long it has to be great right? Not even close. So now that I’ve said all the good there is to say about Javascript, I’ll move on to the bad side of it.

I’ll start with my least favorite feature in Javascript… the type system. I started programming in C++ which is a statically typed language. I grew to love types. To a non-programmer, it may look like it makes things more complicated but in reality, it’s the stark opposite. Javascript by default is a dynamically typed language. This means that all type checking is done at run time rather than at compile time (as is the case with static type checking). This essentially means that if you create a function foo with parameter bar which you expect to be a string, you have no way of knowing for sure that bar is not a string until the program is running. This makes debugging quite annoying since it’s not obvious at a glance what types should be what.

For my non-technical people with no idea what functions are, I’ll leave you with the following example. So what I’m going to have you visualize is the following function:

function clap(times) {
  for (let i = 0; i < times; i++) {
    console.log("clap");
  }
}

clap(5); // Valid code

This is essentially me telling the computer to print “clap” to the console the exact number of times specified. This can be put in human terms by you telling your friend to “clap 5 times” for example. Now the issue lies with if you say “clap parrot times”. What do you do in this case? It shouldn’t be allowed. The instructions were “clap” followed by a number. For humans, this would simply result in the person asking you what to do but the computer doesn’t have that luxury. If you weren’t aware enough to catch errors (maybe thinking “This will always be a number”) then the entire application might crash. My issue with Javascript is it will allow you to do exactly that. While this is unlikely to occur due to IDEs and linters, the following function call would not through a compiler error and will execute until a certain point.

// assuming the clap function above exists
clap("parrot"); // completely error free

Typescript is one potential way to solve this issue. Typescript is a superset of Javascript. It is important to remember the term superset in this case. It adds what is essentially a layer on top of Javascript for developers to introduce “static” type checking.

For example, I’ll rewrite the clap function above in Typescript.

function clap(times: number) {
  for (let i = 0; i < times; i++) {
    console.log("clap");
  }
}

clap(5); // Valid
clap("parrot"); // Invalid (compiler and tools reject it)

Take note of the number keyword. times: number says to the compiler that times will be a number. If the compiler receives a string value it will immediately flag that as an error and, if using strict types, will not compile.

The issue with Typescript is that it is a superset. It is designed to be compatible with standard ECMAScript (Javascript). An easier way to think of this is that Typescript code will not run in a .js file, while Javascript code will run in a .ts file. Being a superset means it has to take into account that there may be instances where a variable will be of a dynamic type. In this case, the compiler will have no idea what the type of the variable is. For this reason, the any type was added. The any type is essentially the developer telling the compiler that they’d like to opt out of type checking. From this point onwards, unless the value is cast to another type, the compiler has no clue what type the variable is and, for the most part, allows any operation to be performed.

If a system is built from the ground using the best Typescript practices, it would be amazing. However in large teams, shipping many lines of code, under tight deadlines, sometimes the only solution in this situation is for them to use any. In my opinion, as a code reviewer, practically all uses of any should result in a request for changes. At some point, someone would come into contact with this code, maybe not the creator, and they’ll be forced to parse through the code to figure out what that one any variable is.

In my humble opinion, if you’re going to use Typescript, you might as well follow best practices AND use strict mode. If you don’t want to use it, you might as well use plain old Javascript.