Pros and cons
Honest trade-offs of TypeScript, and when not to use it.
TypeScript pays for itself on teams and long-lived code, and charges rent everywhere else. Interviewers ask "when wouldn't you use it?" to check you see both sides — memorize the honest version below.
Where it wins
Refactors stop being scary: rename a field and the compiler lists every
caller you missed. Onboarding gets faster because signatures document
themselves — a new hire reads chargeCard(amount: number, currency: string) instead of guessing. Typos and swapped arguments fail in the
editor, minutes after writing, instead of in production weeks later.
Where it costs
Small scripts and prototypes move slower: every quick experiment wants annotations, config, and a build step. Library boundaries leak complexity — someone must write and maintain type definitions, and advanced types can puzzle readers more than the runtime code they describe. Build times grow with project size (one reason the native 7.0 compiler landed in 2026), and types can never validate external data: an API can still send whatever it wants at runtime.
When not to use it
Skip it for throwaway scripts, one-off migrations, and tiny static pages with no logic worth checking. Skip the strictest settings on week one of a brownfield migration — partial adoption beats an all-or-nothing stall (see migrating a JavaScript project). And never treat a green check as proof: it proves consistency with your annotations, not with reality.
Interview questions
What are the main benefits of TypeScript?basic
You catch wiring mistakes early, document intent in the code itself, and get far better editor help — accurate jumps, autocomplete, and renames that update every caller. Refactors that feel risky in JavaScript become mechanical: change a shape and the compiler lists every place to fix. For shared libraries, published .d.ts files let consumers use your API correctly without reading the source. The payoff grows with codebase size and team size.
Interviewers also ask
- How do types help when refactoring?
What are the main costs of adopting TypeScript?basic
You pay in setup and upkeep: a build step, a tsconfig.json to maintain, and annotations to write for every boundary. Third-party libraries occasionally need extra @types packages or small local declarations. Beginners also fight the compiler at first, especially around null and third-party shapes. For tiny scripts the overhead can outweigh the help, so weigh the long-term maintenance win against the short-term slowdown.
Interviewers also ask
- What extra packages do untyped libraries sometimes need?
When should you NOT use TypeScript?intermediate
Skip it for throwaway scripts, quick prototypes, and tiny automations where a build step slows you down more than types help. It also adds friction to highly dynamic code — heavy metaprogramming or loosely shaped plugin systems can force you into any everywhere, defeating the purpose. If your team will not maintain the types, an untyped codebase with good tests beats a half-typed one that everyone ignores. Choose the tool that fits the lifespan of the code.
Interviewers also ask
- What is a better fit than TypeScript for a one-off script?
How does TypeScript compare to JavaScript with JSDoc type checking?intermediate
Both give you editor help and tsc checking, but JSDoc keeps you in plain .js with types written as comments, while TypeScript uses dedicated .ts syntax. JSDoc suits gradual adoption or teams that cannot add a build step, since the code runs as-is. Full TypeScript scales better: its syntax stays readable for complex generics, and refactoring tools understand it more reliably. You can even mix them with allowJs and checkJs during a migration.
Interviewers also ask
- How would you check plain JS files with the TypeScript compiler?