Languages

TypeScript

JavaScript that scales (when you need it)

Assessment
Trial
Ring
status
Languages
Quadrant
category
2025-11
Updated
last eval
2
Related
technologies

Why Trial (Not Adopt)

TypeScript is objectively better than JavaScript for large codebases. The type safety catches bugs before runtime and the IDE experience is superior.

But I’m placing it in Trial, not Adopt, because most of my JavaScript doesn’t need it.

Where I Use TypeScript

  1. Cloudflare Workers - The FlowLink redirect service is TypeScript. Types help when working with KV storage and request/response objects.

  2. Shared libraries - Any code that might be used across projects gets types.

  3. Complex client-side logic - When Stimulus isn’t enough and I need real state management.

Where I Skip TypeScript

  1. Simple Stimulus controllers - 20 lines of JS doesn’t need types
  2. One-off scripts - Build scripts, data migrations
  3. Rapid prototyping - Types slow down experimentation

The Honest Trade-off

TypeScript adds cognitive overhead. You’re now thinking about:

  • Type definitions
  • Generic constraints
  • Module resolution
  • Build configuration

For a solo developer, that overhead has a cost. The question is whether the bug prevention is worth it.

My answer: it depends on the code’s lifespan and complexity.

Configuration Tips

If you do use TypeScript, use strict mode:

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

Loose TypeScript is the worst of both worlds—all the overhead, none of the safety.

Quick Facts

My Verdict
Essential for large JS codebases, overkill for small ones
Use Cases
Large JavaScript applications Shared code libraries API clients Team projects

Stay updated on my tech choices

Get insights on tools, frameworks, and technologies I'm evaluating for my builds.

Subscribe Free