I’ve spent too much time in codebases where the type system was treated like a suggestion box. You’d see any sprinkled around like cheap salt, or a labyrinth of generics so complex that reading the function signature took longer than understanding the logic. Somewhere along the way, we confused type safety with type convenience. They aren’t the same thing. One prevents bugs; the other just makes your IDE autocomplete look pretty. If you don’t know the difference, you’re probably writing code that feels safe but is actually a house of cards.
What Type Safety Actually Means
Type safety is a guarantee. It means the language runtime or compiler will stop you from performing an operation on a value that doesn’t support it. You can’t call .toUpperCase() on an integer. You can’t pass a string to a function expecting a file handle. If you try, the program refuses to compile or throws a hard error before any damage is done. That’s the contract.
But here’s where the industry gets sloppy. Many developers think that simply having types is the same as being safe. They write const name: string = "Raj" and pat themselves on the back. That’s not safety. That’s just annotation. True type safety is about making impossible states unrepresentable. It’s about ensuring that if a variable is a User, it actually has an email field, and that email field isn’t null unless you explicitly said it could be. It’s about the compiler catching you when you forget to handle the LoggedOut state in your authentication reducer.
I’ve watched teams adopt TypeScript and immediately reach for as any to silence the compiler. They wanted the autocomplete without the discipline. That’s not type safety. That’s a security blanket full of holes.
The Seduction of Type Convenience
Type convenience is that warm, fuzzy feeling when your IDE shows you a list of methods after you type a dot. It’s renaming a symbol across a project without a find-and-replace nightmare. It’s the speed of development when the tooling just hums. And it’s dangerous precisely because it feels so productive.
I’ve seen teams ship entire features using any and as casts, congratulating themselves on the velocity. The types were there, technically. The IDE was happy. But the runtime? That’s where the undefined is not a function errors lived. They had type convenience, not type safety. The types were a costume, not a skeleton.
The real trap is that type convenience often masquerades as safety. You get red squiggles when you misspell a property. You get autocomplete. But if you’re using Partial<SomeType> everywhere because you can’t be bothered to define the exact shape of your data at each step, you’re just pushing the uncertainty down the stack. Eventually, it bites you.
Where the Lines Blur
Let’s get concrete. Consider a function that fetches user data from an API. A type-convenient approach might look like this:
async function getUser(id: string): Promise<any> {
const response = await fetch(`/api/users/${id}`);
return response.json();
}
You get your data. You can access .name in your component. The IDE doesn’t complain. But you’ve just lied to the type system. You have no idea what the API actually returned. If the backend changes the shape of the response, your app breaks silently at runtime. That’s type convenience. It’s a lie wrapped in a Promise.
A type-safe version requires more work upfront:
interface User {
id: number;
name: string;
email: string;
}
async function getUser(id: string): Promise<User> {
const response = await fetch(`/api/users/${id}`);
const raw: unknown = await response.json();
if (isUser(raw)) {
return raw;
}
throw new Error('Invalid user data');
}
function isUser(data: unknown): data is User {
return (
typeof data === 'object' &&
data !== null &&
'id' in data &&
'name' in data &&
'email' in data
);
}
This is slower to write. It’s annoying. It’s also correct. The type guard isUser actually validates the shape of the data at runtime. The type system now reflects reality, not wishful thinking. This is the difference between a type system that documents your code and one that enforces it.
The Cost of Convenience
I’m not a purist. I don’t think every line of code needs a formal proof. But I’ve felt the cost of prioritizing convenience over safety. It’s the 3 a.m. call because a field that was “always there” suddenly isn’t. It’s the week-long debugging session because someone passed a string where a number was expected, and the coercion logic silently produced garbage. It’s the slow rot of a codebase where nobody trusts the types anymore, so they add defensive checks everywhere, bloating the code and killing performance.
Type convenience is a short-term loan with high interest. You get speed now, but you pay in reliability later. And the interest compounds. Every any you cast, every as you assert, every Partial you sprinkle weakens the entire system. The compiler becomes a liar. And when the compiler lies, you’re back to writing JavaScript with extra steps.
Practical Type Safety Without the Dogma
So how do you stay safe without drowning in boilerplate? I’ve settled on a few rules that keep me honest.
1. Validate at the Boundaries
Your application has edges: API responses, form inputs, local storage reads. That’s where the unknown lives. Don’t let it in. Parse and validate at the boundary, then let the rest of your code trust the types. Libraries like Zod make this less painful, but even a hand-rolled type guard is better than a cast.
2. Avoid any Like a Bad Habit
If you’re using any, you’re opting out of the type system. There’s almost always a better choice: unknown for truly dynamic data, Record<string, unknown> for objects you haven’t modeled yet, or a proper generic. any is a signal that you’ve given up. Don’t give up.
3. Make Impossible States Unrepresentable
This is the heart of type safety. If your component can be in a loading, error, or success state, model that explicitly with a union type. Don’t use a boolean isLoading flag and hope nobody accesses the data before it’s ready. The type system should make that mistake impossible to compile.
type AsyncState<T> =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'error'; error: string }
| { status: 'success'; data: T };
Now you can’t forget to handle the error case. The compiler won’t let you. That’s safety.
4. Prefer Exhaustiveness Checks
When you have a discriminated union, use a switch statement with a default case that assigns to never. If you add a new variant and forget to handle it, the compiler will catch you. This is a simple, powerful pattern that costs almost nothing to implement.
When Convenience Is Acceptable
I’m not saying you should never take shortcuts. Inside a well-tested, isolated function, a type assertion can be fine. If you’re prototyping and the code will be thrown away, go wild. But the moment that code is shared, imported, or persisted, the safety net needs to be there. The line is: will this type cross a trust boundary? If yes, validate it. If no, you can be a little looser—but only a little.
I’ve also found that convenience types are acceptable when the alternative is a generic so abstract that nobody on the team can read it. If your compose function requires a PhD in category theory, you’ve lost the plot. Types should clarify, not obfuscate. Sometimes a slightly less safe, more readable type is the right call. But that’s a conscious trade-off, not a default.
The Social Side of Type Systems
Type safety isn’t just a technical property. It’s a social contract. When you write a function signature, you’re making a promise to every developer who will ever call that function. If you lie in the signature—by returning any, by using overly permissive types, by not validating inputs—you break that promise. The next developer trusts the types, writes code that compiles, and ships a bug. That’s on you.
I’ve seen this erode team trust. Developers start adding null checks everywhere because they don’t trust the types. They write defensive code that obscures the actual logic. The codebase becomes a mess of if (data != null && data.property != null) checks, not because the data is actually nullable, but because someone once returned a null and nobody trusts the types anymore.
Type convenience is selfish. It optimizes for the writer at the expense of every future reader. Type safety is generous. It costs the writer a little more time, but it saves everyone else hours of debugging and confusion.
FAQ
Isn’t TypeScript already type-safe by default?
No. TypeScript is a superset of JavaScript, and it allows you to opt out of type checking entirely with any, as casts, and loose compiler options. Type safety is a practice, not a language feature. You have to configure it strictly and enforce it through code reviews and lint rules. A default TypeScript project is not safe.
When should I use unknown instead of any?
Use unknown whenever you have a value whose type you truly don’t know—like the result of JSON.parse() or a third-party API response. unknown forces you to narrow the type before you can use it, which is exactly what you want. any disables narrowing. If you’re not sure, unknown is the safer default.
How do I convince my team to care about type safety?
Don’t preach. Show them the bugs. Find a production incident caused by a missing type check, and walk through how a stricter type would have prevented it. Concrete pain is more persuasive than abstract principles. Also, introduce safety incrementally: start with strict null checks, then add a validation library at the API boundary. Small wins build momentum.
Are generics always safer than using any?
Not always. A poorly designed generic can be just as misleading as any. If your generic doesn’t constrain the type parameter, you’re essentially saying “this could be anything,” which is the same lie. Generics are powerful when they preserve relationships between types—like ensuring a function returns the same type it receives—but they’re not a magic safety wand. Use them deliberately.
When you strip it all down, type safety is about honesty. Be honest about what your code expects and what it returns. Don’t lie to the compiler, and don’t lie to your teammates. The convenience isn’t worth the cost.