TypeScript Won. Here's What That Actually Bought Us.
The 'should we use TypeScript?' debate is over. The interesting question is what all those types are quietly enabling now.

Nobody seriously argues about adopting TypeScript anymore. New frontend projects default to it; the holdouts are legacy codebases and the occasional throwaway script. The debate is over, TypeScript won.
But "won" is the boring part. The interesting part is what types turned out to be good for — which is more, and different, than the original pitch of "catch typos before runtime."
A function signature is documentation that can't go stale, because the compiler fails the build the moment it lies.
You already know almost everything about calling this without reading a single comment: what it needs, what it returns, that channel is one of exactly three strings. A comment claiming the same things could rot the next time someone adds a "slack" channel and forgets to update it. The type can't — adding "slack" to the union forces every call site to be reconsidered.
In a large untyped codebase, renaming a widely-used field is genuinely scary — you're grepping strings and praying. In a typed one, you change the type and the compiler hands you the complete to-do list of everything that broke. Refactoring stops being "risky" and becomes "tedious but safe," which is exactly the trade you want. Whole categories of "we can't touch that, it's too entangled" simply dissolve.
Here's the part that wasn't in the original sales pitch. The more machine-readable your boundaries are, the more reliably an AI assistant can operate inside them.
Ask a model to "add a field to this object" in untyped JavaScript and it's guessing at shape from usage. Ask it in TypeScript and the type is the spec — it knows precisely what's allowed, and its mistakes surface as compile errors instead of 2am production incidents. Types turn "generate plausible code" into "generate code that provably fits."
This flips an old objection on its head. People used to say types slowed them down. In an AI-assisted workflow, types speed you up, because they're the guardrail that lets you accept generated code with confidence instead of auditing every line by hand.
If types are this leverage-rich, it's worth writing them with intent rather than appeasing the compiler:
- Prefer unions over booleans + optionals.
status: "loading" | "error" | "ready"beats three independent boolean flags that can contradict each other. - Name your domain types.
type Cents = numberdocuments intent at every use site and lets you tighten it later. - Avoid
any; reach forunknownand narrow.anyis a hole in exactly the safety net you're paying for. - Let inference work. You don't need to annotate everything — annotate the boundaries (function signatures, exported APIs) and let the rest flow.
TypeScript's real win wasn't catching typos. It was turning your codebase into something with explicit, enforced contracts — and contracts turn out to be exactly what fearless refactoring, reliable tooling, and trustworthy AI assistance all quietly depend on.
We adopted types to prevent a class of bugs. We're keeping them because they're the substrate everything else now builds on. Worth investing in writing them well.
Thanks for reading! Let's stay connected:
- ⭐ GitHub — follow me and star the projects: github.com/parsajiravand
- 💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
- 📸 Instagram — frontend best practices, daily: @bestpractice___
- 💼 LinkedIn — linkedin.com/in/parsa-jiravand
- ✉️ Email (work & contract inquiries): bestpractice2026@gmail.com
Originally published on dev.to