A Glimpse at Typescript

Some discussion has come up within the frontend team at work over whether Typescript is something worth including into our workflow and tooling in the not so distant future. But what’s at stake when deciding to include Typescript in a project, and why would we even need it in the first place? I decided to do a little research on the language, and present my findings here in this very short little blog post.

The resource I explored was Learning Typescript by Josh Goldberg. In it he explains that Typescript is a valuable tool which addresses some of the deficiencies that plain Javascript may leave behind. He describes three pitfalls of Javascript. They are:

1. Costly freedom:

   1. Javascript runs code without first checking it it will likely crash.

   2. It’s hard to tell what a function does without knowing the codebase or reading documentation (if it exists at all!), which leads us to number two…

2. Loose documentation:

   1. There’s nothing native to Javascript to describe what is going on in, say, a function - for instance, what the parameters of the function should be.

   2. JSDoc standard does exist, but it is not required as a part of the development process, and it doesn’t automatically adjust with refactoring - first you have to refactor code, then you still have to refactor documentation, as there is no automation in this process.

   3. Types and relationship descriptions are unwieldy and verbose…

   4. …and it’s hard to maintain over hundreds (or more!) of files.

3. Weaker developer tooling:

   1. It’s hard to automatically change things with Javascript. You have to do a lot of things by hand (for above reasons).

   2. This means it’s harder for dev tools like VS Code to pick up on syntax/structure highlighting and give intelligent feedback to the developer.

Now let’s take a look at what Typescript has to offer. Typescript is a programming language built on top of Javascript, meaning that any code you write in Javascript will also work in Typescript. Additionally, Typescript provides syntax for defining and using types. Typescript is also a type checker: a program that analyzes a set of JavaScript or TypeScript files to alert you of potential runtime errors. Typescript is a compiler as well: It executes the type checker, identifies any issues, and then generates the equivalent JavaScript code. And lastly Typescript is a language service: A program that leverages its type checking functionality to guide code editors in offering valuable suggestions to developers.

So does Typescript solve these Javascript shortcomings described above? In short, Typescript is:

1. Beneficially restrictive:

   1. Typescript checks your types and whether a type error will likely crash your code, before it runs.

2. Self-documenting:

   1. Typescript is self-documenting to an extent, because you have to tell it what type values like your variables, function parameters, and returned values from functions are, ahead of time.

3. Stronger at developer tooling:

   1. These features in turn allow developer tooling like VS Code to pick up on syntax highlighting and make intelligent code suggestions (even without copilot!).

Some developers argue that having to write with specific types in mind is too restrictive, but Goldberg answers,

“But! I would argue that being ‘restricted' in this way is actually a good thing! By restricting our code to only being able to be used in the ways you specify, TypeScript can give you confidence that changes in one area of code won’t break other areas of code that use it.”

(from Learning Typescript)

It’s worth restricting certain development behaviors if it means more predictable and extensible code.

Now for a fun case study in which Typescript could have been applied to avoid errors!

We had a small bug in the one of our projects that could have been caught with Typescript (and I’m guessing more, larger bugs that could’ve been as well). The value for a certain variable, let's call it myStatusVariable for a certain status was supposed to be a string - "0" - not a number. The status display relied on myStatusVariable being a string, or it would not show. Well in one portion of the code I had it set to a number (oops!) and this was causing a brief (but possibly for some users not so brief) delay in the status showing, because it was a the wrong type. With Typescript we could have set the type for myStatusVariable to be "string" and it would have given a red squiggly error line when I set the value to a number - all before program execution or deployment.

Conclusion?

So is Typescript worth it? The classic developer answer is, It depends. Typescript provides solid support in the area of type safety, but it won’t solve every problem. In my opinion one of the nicest things about Typescript is that you get to see errors before you run your code, as opposed to in Javascript where your program can just silently crash. Furthermore tooling exists in libraries such as Vue which support adding Typescript in gradually, so you don’t have to worry about converting an entire codebase to Typescript all at once.

Thanks for staying with me in this little intro to Typescript! I may add to this post in the weeks to come, as I learn more, so keep an eye out for that.