Opinion: When Not to Use TypeScript — A Balanced View

Thesis: TypeScript is an excellent tool, but it has costs — cognitive overhead, compilation, and complexity for certain projects. Recognizing when to skip TypeScript can save time and reduce unnecessary complexity.

“Every tool has a trade-off. Using TypeScript because it's popular is not the same as using it because it fits the problem.”

When JavaScript might be better

• Tiny prototypes and experiments: If you’re exploring an idea, the iteration speed of plain JavaScript can be beneficial. The cost of introducing TypeScript may slow you down for throwaway prototypes.
• Simple scripts and glue code: Short scripts that manipulate files or orchestrate commands may not benefit from a typed contract.
• Teams without buy-in: If the team is not aligned on adding typing discipline, partial TypeScript can lead to a mixture of poor-quality types that add maintenance overhead.

Beware of false economies

Some argue TypeScript is unnecessary for small projects, but if the project is expected to grow or be maintained over time, early typing can pay dividends. The key distinction: short-lived experimentation vs long-lived software.

When TypeScript is clearly worth it

• Public APIs and libraries where users rely on types.
• Large codebases with multiple contributors.
• Safety-critical business logic where invariants matter.

Alternative approaches

If TypeScript doesn’t fit, consider lightweight alternatives:

• JSDoc with checkJs for basic type checking without full TypeScript setup.
• Runtime validation libraries like AJV or Zod to enforce schemas at runtime.
• Gradual adoption: keep core modules typed and leave peripheral scripts untyped.

People and process matter more

Adopting TypeScript is not just a technical change; it changes code review, onboarding, and design conversations. If your team lacks time for documentation and reviews, introducing types can become a burden rather than a benefit.

Final thoughts

TypeScript is a powerful tool, and saying "not now" can be the right decision for particular contexts. The pragmatic approach is to align tool choice with product lifecycle and team constraints. When in doubt, prototype in JS, evaluate the expected lifespan and maintenance, and adopt TypeScript when the benefits justify the costs.

Advice: Revisit the decision periodically — as the project evolves, the calculus may change in favor of TypeScript.