Alternatives to TypeScript

Hello, and welcome to my Talk, Alternatives to TypeScript. While I'm a big fan of TypeScript, no language exists in a vacuum. They all influence and inspire each other. Who am I? My name is Ashley Claymore and I work as a software engineer at Bloomberg. I've been using TypeScript for six years now, meaning I've got to see how much it's evolved. I've also contributed to TypeScript and I'm a TC39 delegate.

So what are some of the alternatives? We have Clojure, we have Flow and we also have Hagel. People might be more familiar with the Clojure compiler as a JavaScript optimizer, and that's because it does really good job of optimizing JavaScript. Projects like React, which use Flow as the type checker, they then also use Clojure to optimize the code. Clojure does also have a type checker and it supports either JS doc or this more minimal start of type comment that I'm showing here. As far as I could tell, there isn't a Clojure language server that gets the errors to show up interactively, instead you run the compiler more like a traditional compiler. Unfortunately I only have a few minutes, I'm not going to have time to dig further into Clojure but if you're interested, please do go check it out.

Okay, there's a big block of code here and don't worry about trying to read it. The important thing I'm trying to show is that in this whole snippet, it's syntactically valid in all three, Hagel, Flow and TypeScript. This tells us they all have a similar look and feel to them, but they do diverge and for the rest of this talk, what I'm going to do is just going to give you a flavor of how they are different to each other. So for example, in Flow and Hagel, they're generic type constraints. They use a colon instead of an extends keyword. They also have this prefix union question mark operator, and they also allow parameter names to be emitted in function types. Flow primarily and Hagel exclusively use their built-in utility types when you're doing type manipulation instead of having some extra additional dedicated syntax for doing that. And then, these utility types are implemented directly in their compilers. If you compare that to the TypeScript approach, where almost all of the utility types are aliases for the syntactic way of doing that type manipulation, things like map types and conditional type syntax. If I create a type hierarchy diagram, that lets us compare a few differences in how the systems model their types. One time that Hagel is taking a different approach is that it doesn't have an any type. The closest you can get is to the safer unknown type. Flow does have any, and their unknown type, they call that mixed instead. And Flow also calls their bottom type empty instead of never. Where TypeScript has both a void and an undefined type, Flow only has void and Hagel only has undefined. TypeScript also put their object literal type much higher up, up above the primitives, whereas Flow and Hagel make this finer distinction between what's a primitive, array, a function, and what object literal types describe. I have an example of that coming up. Firstly, Flow and Hagel have this concept that types can be closed by default.

So, in this example, because I only mentioned the path property, when values are passed in that have additional properties, that's treated as an error, even if it's not done inline. If you're okay with having additional properties passed in, you need to add dot, dot, dot to the type. That tells us it's now an open type.

This is an example that's coming up. It shows how Flow and Hagel treat their object literal type I'm passing a string and trying to pass an array to a function where I said give me something with a length property. As JavaScript developers, we know these things, you can access a length property, but that's getting an error here. That's because of that finer distinction between these types. If we need to include them, then I have to explicitly say all string or array or function to say I expect these types to also be okay.

One of the big selling points is that it will flow the types being passed into a function from the call sites. That allows it to check code even if it doesn't have a type annotation. One thing to be aware of with this is that when you add a new call to a function is that that impacts the influence of the same calls to that function in the same file. So here where it's previously inferring a string return type, that's now inferring a string or number because I've introduced a new call that's passing in a different type. Hagle also had a name to be able to check functions even if they don't have type annotations but they took a different approach. Instead, looking at the function implementation, it built up a generic signature that can be reused. Another thing I saw here is that Hagle won't allow it to implicitly infer conversion from number to string. Instead, it must be explicit. TypeScript took a different approach. While it can infer the types for functions without annotations, instead, that's offered as a quick fix instead of using that logic as part of the core type checking. And a general theme that I felt when I was looking at these languages, it seems that Flow tries to be safer than TypeScript, and then Hagle again tries to be more safe than Flow. And Flow and Hagle's more sound interpretation of types can have it can be really subtle. For example, in the type I'm showing here, Flow and Hagle make the technically more sound distinction between these two types, whereas in many situations, TypeScript allows you to use them interchangeably because in many cases, it is okay to use them interchangeably. And then Hagle's goal of not requiring as many type annotations combined with this increased emphasis and focus on safety, it results in a different feel to the JavaScript you write. For example, array literals are inferred as a fixed length double, no need for as const. Hagle also reports an error that I'm not using the return value of push, the new length. I have to use a void expression to make it explicit that I'm doing this for a side effect and not interested in the return value.

Okay. That was a really lightning-fast exploration of these other tools. I hope the one thing I've shown is even though they all start with this same underlying challenge of statically type checking JavaScript, they all have their unique and equally valid approaches. I find that really fascinating. I feel it demonstrates how much creativity pours into these tools. For me, personally, looking at those other tools, helped me better understand TypeScript. So, for people that are TypeScript developers that aren't using these tools, I still think it's worth checking them out. I hope you'll find it interesting as well.