TS Congress

TypeScript Congress 2022

While TypeScript is currently the most popular static type checker for JavaScript, there are alternatives. In this talk, we'll look at Flow.js and Hegel, and review the similarities and differences among the three. Doing this will put TypeScript in perspective, and maybe help explain why the TS team made certain design decisions. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Alternatives to TypeScript

Hello and welcome to my lightning 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. Firstly, 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 Hagle. People might be more familiar with the Clojure compiler as a JavaScript optimizer, and that's because it does a 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. The Clojure does also have a type checker and it supports either JS doc or this more minimal style 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. Hagle, 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 Hagle, their generic type constraints, they use a colon instead of the extends keyword. They also have this prefix union question mark operator, and they also allow parameter names to be admitted in function types. Flow primarily and Hagle 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 Hagle has taken 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 built-in type empty instead of never. Where TypeScript has both a void and an undefined type, Flow only has void and Hagle only has undefined. TypeScript also put their object literal type much higher up, like up above the primitives, whereas Flow and Hagle make this finer distinction between what's a primitive, array, a function, and what object literal types describe. We have an example of that coming up. Firstly, Flow and Hagle have this concept that types can be closed by default. 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 explicitly add dot, dot, dot to the type, and that tells us that it's now an open type. So, this is an example that I said will be coming up. It shows how Flow and Hagle treat their object literal type a little bit differently. So, here I'm passing a string and also trying to pass an array to a function where I've said give me something with a length property. And as JavaScript developers, we know that these things, you can access a length property, but that's getting an error here. And 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 of Flow is that its type inference will flow the types being passed into a function from the call sites. And 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 as 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 just 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, the type that 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 by default as a fixed length tuple, no need for as const. Hagle also reports an error that I'm not using the return value of push, the new length. Instead, I have to use a void expression to make it explicit that I'm doing this just for its side effect and I'm 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 that even though they all start with this same underlying challenge of statically type checking JavaScript, they all have their various unique yet equally valid approaches. And I find that really fascinating. I feel that it demonstrates just how much creativity pours into these tools. And for me personally, looking at those other tools, it helped me better understand TypeScript. So, for people that are TypeScript developers that aren't using these tools, I still think that it's worth checking them out. So, I encourage you to do so. I hope you'll find it interesting as well. Thank you so much for listening.