Why Type Safety
Back in November I asked on Twitter for folks to send me their questions or their points of frustration with TypeScript and React. I got about 20 responses and they were a good crop of questions. On this blog I'm going to start addressing each of them every week, but before I got into specific code examples and details, I felt like it was important to set a baseline for what type safety actually is and what it buys you in a project.
In the last 3 years, I've witnessed TypeScript go from "that thing the Angular fringe"1 of developers use to being the default choice for projects, teams and frameworks. So TypeScript, TypeScript, TypeScript, the favorite tool of object-oriented programmers and the oft-asked for need of reply guys on GitHub. Types shipping with packages, tools needing to support the syntax, better typing for projects.
But it can't be argued, TypeScript is overwhelmingly popular. According to StackOverflow2 in 2020, TypeScript is the most loved language. It's the 9th most popular language among developers and according to GitHub's State of the Octoverse3, its popularity grew 161% between 2018 and 2019.
Now, this may just be me being naive or oppositional or something my therapist has yet to determine: but what does adding TypeScript to a project actually give you? What's the net gain that out weighs the overhead of needing to learn something new?
You're probably scoffing and rolling your eyes with the answer? Charlie, you get type safety.
I've heard this term before, and I've heard the elevator pitch, you catch bugs at compile time (when your code builds) versus run time (when your code executes, like in the browser). Every time someone explains that to me, I feel like I'm missing something.
So let's break it down, what is type safety and how does TypeScript give it to me? Type safety is the extent to which a language discourages, disincentivizes or prevents what we would call a type error.
A type error is an inconsistency between a data type needed and the one being supplied, for instance if you're trying to treat a number as a string or if you're passing a value and haven't accounted for whether it's undefined or not. Type errors are generally bad because in some languages, you won't get an actual program to compile because it won't be able to perform the functions you need it to. Ergo, type safety shows you where your application can break and where the potential is for it to break up front.
From there we can get a snapshot of what type safety is and what it gives you is the reasonable confidence that whatever you're building will do what you actually need it to.
Because of intelligence being added your type annotations, your IDE can more reliably autocomplete statements, auto-import modules, and show all of the given implementations and references of your code across your project. For instance, if you write a function definition in one file, in VS Code you can right-click and see everywhere else in your project you're using that function. You can also do the inverse. If you're using a function or class in one file you can click to go to the original implementation of that piece of code.
Opting to build projects that are type safe gives you the ability to delegate to your environment, to your past self and then gives you the ability to focus on what your project needs to while showing you where it's likely to break.
I know they're not the fringe, let me enjoy my fantasy. ↩