Blog TypeScript everywhere: the good, the cost, the limits
TypeScript everywhere: the good, the cost, the limits
TL;DR TypeScript catches a class of bugs before you run the code and makes large codebases easier to change and navigate. It costs build complexity, some ceremony, and a learning curve, and it does not catch logic errors or bad design. Worth it for most projects of any size, less so for a throwaway script.
TypeScript went from a nice-to-have to something close to a default. That is mostly deserved, but "use it everywhere" deserves an honest accounting rather than a reflex. Here is what it buys, what it costs, and where it stops.
The good
The core benefit is catching a class of bugs before the code runs.
- Fewer dumb runtime errors. Passing the wrong shape, accessing a missing property, forgetting a null. The compiler flags these while you type, not in production.
- Refactoring you can trust. Rename a field or change a function signature, and the type checker shows you every place that needs updating. On a big codebase, this is the feature that pays for the rest.
- Better editor help. Autocomplete, inline docs, and go-to-definition all get sharper because the tools know the shapes.
For anything you will maintain or work on with others, these compound.
The cost
None of it is free.
- Build complexity. You add a compile step and its configuration to your project.
- Ceremony. Some code needs type annotations that add lines without adding behaviour, and occasionally you fight the type checker over something you know is fine.
- A learning curve. Generics, unions, and the trickier corners take time to get comfortable with.
On a small, short-lived script, that overhead can genuinely outweigh the payoff.
The limits
This is the part people skate over. TypeScript checks types, not correctness.
- It will not catch a wrong formula, only a wrong shape.
- It will not save you from bad architecture or a confusing API.
- It will not prevent a logic bug that is perfectly type-consistent.
Types make your code consistent with itself. They do not make it right. The thinking is still yours to do.
The honest verdict
For most projects of any real size or lifespan, TypeScript earns its keep, mostly through safe refactoring and editor support. For a quick one-off, plain JavaScript is often the faster path. Reach for it by default on things you will keep, and skip the ceremony on things you will throw away. Use it as the strong tool it is, not as a promise that the code is correct.
FAQ
What does TypeScript actually prevent?
It catches type errors before runtime: passing the wrong shape to a function, accessing a property that does not exist, forgetting to handle a null. That removes a whole category of the small, avoidable bugs that otherwise surface in production.
Does TypeScript slow you down?
At first, yes, while you learn it and set up the build. Once you are fluent, the editor help and refactoring confidence usually make you faster on anything nontrivial. On a tiny throwaway script, the setup cost can outweigh the benefit.
What are the limits of TypeScript?
It checks types, not logic. It will not catch a wrong calculation, a bad API design, or a race condition. Types are consistent with your code, not proof that the code is correct. It is a strong tool, not a substitute for thinking.