Last quarter we inherited a JS codebase where a function took an order object. Somewhere upstream, six months and three developers ago, someone renamed order.total to order.amount. The old code kept reading order.total. JavaScript said nothing — undefined slid quietly through half the pipeline and landed as NaN on an invoice. A customer found the bug. In production. On a total.

That's the entire point of this post in one paragraph. But let's take it in order.

The war is over — some people just haven't gotten the memo

If you've followed the State of JS surveys over the last few years, the trend isn't subtle. In the latest big snapshot, the single largest group of developers isn't the "a little TS" crowd or the "fifty-fifty" crowd — it's the people writing 100% TypeScript. The group writing pure JavaScript, without a single line of types, has shrunk to a minority. On the Stack Overflow surveys JavaScript still holds the #1 spot for usage, but TypeScript has been climbing toward the top for years and is now one of the most-used languages, full stop.

Translated into plain terms: in 2026, TypeScript is no longer the "advanced option" or a matter of taste. It's the default. New Next.js, Nuxt, Vite, Angular, Deno, Bun — they all greet you with a .ts extension, no questions asked. Once a tool becomes the assumption baked into the entire ecosystem, avoiding it stops being a neutral choice. It becomes a cost.

What avoiding TS actually costs

This isn't about ideology. It's about a bill someone eventually pays.

Runtime bugs the compiler catches for free. That order.total example isn't exotic — it's the most mundane class of bug there is, and JavaScript specializes in letting it slip through. With types, there's no debate:

interface Order {
  amount: number;
  currency: "EUR" | "USD";
}

function formatInvoice(order: Order) {
  // order.total -> Property 'total' does not exist on type 'Order'.
  return `${order.amount.toFixed(2)} ${order.currency}`;
}

The error happens in the editor, before the commit, before the deploy, before a customer ever sees a NaN. That's a cheap bug — the cheapest kind. A production bug is the most expensive.

Slower onboarding. When a new developer opens an untyped JS project, processPayment(data, opts) tells them nothing. What's data? Which keys live in opts? The answer is: read the whole codebase, grep the call sites, or ask the person leaving in three weeks. With types, the function signature is the documentation. Autocomplete knows everything. The new hire is productive in days instead of weeks — and onboarding is pure cost for as long as it lasts.

Harder maintenance. Software isn't written once. It lives for years, gets touched by a dozen people, and every change is a bet that nothing else breaks. In JS that bet is blind. In TS the compiler is the thing that tells you where you forgot a consequence.

More expensive refactoring. This is where the gap turns dramatic. Rename a field in a large TS project and the editor shows you all 47 places to touch, in a second. In untyped JS the same refactor is grep, a prayer, and regression bugs you find a week later. Teams avoid refactoring in JS precisely because it's risky — so the code rots, technical debt piles up, and "we'll fix it later" becomes "nobody dares touch that."

"But it slows us down"

The most common objection. And it's partly fair — for the first week. There's a setup cost, a cost to learning generics and utility types, a cost to @types packages for older libraries. That's real.

But it's a one-time cost you pay up front, and it gets refunded every single month of maintenance afterward. Every team that has gone through it tells the same story: the first couple of weeks are friction, and then they never go back. Not because it's trendy — because the compiler does the work a human would otherwise do, slower and with mistakes.

There's also a sensible middle ground worth naming. You don't have to go strict: true on day one. Gradual migration — allowJs, then file by file, then tightening the rules — is a legitimate strategy for a legacy codebase. TypeScript doesn't force you to cannonball in. But "we'll start someday" and "never" look identical in practice.

The bottom line

In 2026 the question isn't "should we use TypeScript." The ecosystem answered it for you. The question is how many more NaNs on invoices, how many slow onboardings, and how many refactors everyone's afraid of you plan to pay for before you accept what's already become the default.

Related:

• Vibe Coding Is Great — Until It Hits Production
• 84% of Developers Use AI Tools. So Why Isn't the Code Better?

Inherited an untyped codebase and don't know where to start migrating? Or building something new and want it done right the first time? Get in touch — that's the work we do.