TypeScript vs JavaScript: When Static Types Are Worth the Overhead

Your new backend developer pushes their first PR. Everything looks clean — good naming, sensible structure. Then the reviewer spots it: a function that accepts userId as a parameter, but half the callers pass a number and the other half pass a string. The bug only surfaces in production when a database lookup silently returns nothing.

"If we used TypeScript," someone comments, "this would have been a compile error."

"We already have enough build complexity," the lead responds.

And now you've got a thread.

This debate used to be more balanced. In 2026, it isn't — but the nuance still matters, because the question isn't whether TypeScript is technically better. It's whether the overhead is worth it for your situation.

Quick Decision Matrix

The Core Difference (It's Not What You Think)

JavaScript and TypeScript produce identical output. TypeScript compiles to JavaScript. The browser, Node.js, Deno — they never see a .ts file. What TypeScript gives you is a separate analysis layer that runs at build time and in your editor, catching a class of bugs that would otherwise only appear at runtime.

That's it. There's no runtime performance difference. No different VM. TypeScript is JavaScript with a spell-checker that understands types.

The philosophical split is about when you want to know about bugs. JavaScript says: you'll find out when the code runs. TypeScript says: you'll find out when you type it.

This sounds like an obvious win for TypeScript. But the cost is real: you have to annotate your code, configure a compiler, and occasionally fight the type system on things it can't infer. For a 50-line script you'll run once, that cost is pure overhead. For a 50,000-line API you'll maintain for three years, it pays back many times over.

The Build Pipeline (2026 Edition)

The "TypeScript has build overhead" argument made sense in 2019. tsc was slow, and the toolchain was messy. That's not the 2026 reality.

Modern tools don't use tsc to transpile. They use esbuild (written in Go) or SWC (written in Rust), which just strip types and emit JavaScript — no type checking, near-instant. Type checking runs separately (via tsc --noEmit) either in your editor or as a CI step.

# What actually happens in a Vite project:
# - esbuild/SWC strips type annotations on every file change (no type analysis)
# - tsc --noEmit runs in watch mode for type errors: separate process
# - Your HMR is unaffected by type check time

The result: your dev server starts just as fast as a plain JavaScript project. HMR is just as quick. TypeScript's type checking is parallel — it doesn't block your build.

The practical difference at a project level: one extra tsconfig.json to maintain. That's genuinely all.

What You Actually Catch

You'll see a percentage quoted for this — "TypeScript catches N% of bugs" — and it's usually a number someone made up or a single academic result stripped of its sampling caveats. Ignore it. What's useful is knowing the shape of the bug class it catches, because that determines whether it matters for your codebase:

• Wrong argument types to functions
• Missing null/undefined checks
• Typos on property names
• API response shapes changing without callers being updated
• Renamed functions/methods with some callers still using the old name

Here's the canonical example. In JavaScript:

// api.js
async function getUser(userId) {
  const res = await fetch(`/api/users/${userId}`);
  return res.json();
}
 
// somewhere else, six months later
const user = await getUser(req.query.id); // query params are always strings
console.log(user.name.toUpperCase()); // TypeError if user not found: Cannot read properties of undefined

In TypeScript:

// api.ts
interface User {
  id: number;
  name: string;
  email: string;
}
 
async function getUser(userId: number): Promise<User | null> {
  const res = await fetch(`/api/users/${userId}`);
  if (!res.ok) return null;
  // `res.json()` is Promise<any>, so `as User` on it is itself a type error
  // (TS2352) — the cast belongs on the awaited value.
  return (await res.json()) as User;
}
 
// Now the caller can't ignore the null case:
async function handler(req: Req, res: Res) {
  const user = await getUser(Number(req.query.id));
  if (!user) return res.status(404).json({ error: "Not found" });
  console.log(user.name.toUpperCase()); // TypeScript knows user is User here
}

The types also serve as documentation. Six months later, a new developer reads getUser and immediately knows: it takes a number ID, returns a User or null, and what User looks like. No hunting through the database schema.

IDE and AI Tooling

This is where the 2026 case for TypeScript is strongest and most underrated.

Every modern editor (VS Code, WebStorm, Neovim with LSP) gets dramatically better with TypeScript:

• Autocomplete on object properties (including nested)
• Inline documentation on hover
• Rename symbol across the entire codebase
• "Find all references" that actually works
• Import suggestions that know what's exported

With JavaScript, you get some of this via JSDoc inference, but it's incomplete. The editor is guessing.

Now add AI coding tools. The mechanism here is simple and doesn't need a benchmark to justify: an agent editing a typed codebase can check its own work. tsc --noEmit is a fast, deterministic oracle that says "this call site is wrong" without running anything. In a plain-JavaScript repo the only oracle is the test suite, which is slower, less complete, and won't tell you that you passed a string where a number was expected.

The secondary effect is context. Type annotations and interface declarations at each call site describe the data without the model having to infer it from usage. That's the same reason they help a human reading the file cold.

I'd rather not put a number on either effect — I haven't measured one, and the published claims I've seen aren't methodologically solid enough to quote.

Configuration: The Real Overhead

The actual tax you pay is tsconfig.json. Here's a sane default for a Node.js project in 2026:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "strict": true,
    "outDir": "dist",
    "rootDir": "src",
    "skipLibCheck": true
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

For a Next.js, Vite, or Astro project, the framework generates this for you. For a new Node.js project, you're looking at 10 minutes to set this up once.

The more consequential choice is "strict": true. It's an umbrella that turns on a family of flags; the two you'll actually feel are:

• noImplicitAny — a parameter with no annotation and no inferrable type is an error, not an implicit any
• strictNullChecks — null and undefined stop being assignable to everything

Skip strict: true and you get TypeScript with training wheels — it mostly stays out of your way. Enable it and the type checker becomes genuinely rigorous. Most teams should start strict. Retrofitting strictness on an existing codebase is painful.

Node.js Type Stripping (The 2026 Context)

Node.js 22.6 shipped --experimental-strip-types, which lets Node run TypeScript files directly by stripping type annotations on the fly. Node 23.6 unflagged it, and the change was backported to 22.18 — so on any current LTS, node script.ts just runs.

# Node 22.6 – 22.17: behind a flag
node --experimental-strip-types src/server.ts
 
# Node 22.18+ and 23.6+: on by default
node src/server.ts

This changes the calculus for scripts and small tools. You can write .ts files with full type annotations, get editor support and type checking, and run them with node directly — no tsc, no ts-node, no build step.

The restriction is that stripping only erases; it never emits new JavaScript. So any TypeScript construct that has a runtime representation is rejected outright rather than compiled. On Node 22.22.3, these are the errors you get:

$ node enum.ts
SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum is not supported in strip-only mode
 
$ node namespace.ts
SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript namespace declaration is not supported in strip-only mode
 
$ node param-props.ts
SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript parameter property is not supported in strip-only mode

Note that it's enum in general, not just const enum — and constructor parameter properties (constructor(private x: number)) are out too, which is the one that bites hardest if you're coming from a NestJS-shaped codebase. Setting "erasableSyntaxOnly": true in tsconfig.json makes tsc flag these at author time instead of letting Node fail at startup. Everything else in modern TypeScript — annotations, interfaces, generics, satisfies, type-only imports — strips cleanly.

For one-off scripts, this eliminates the last remaining argument for plain JavaScript.

The JSDoc Middle Ground

There's an option people don't talk about enough: JavaScript with JSDoc type annotations.

TypeScript's language server can type-check .js files when you add JSDoc comments and enable // @ts-check at the top. You get editor autocomplete, inline errors, and some compile-time safety — without a build step or a .ts file.

// @ts-check
 
/**
 * @param {number} userId
 * @returns {Promise<{id: number, name: string} | null>}
 */
async function getUser(userId) {
  const res = await fetch(`/api/users/${userId}`);
  if (!res.ok) return null;
  return res.json();
}

This is genuinely useful for:

• Scripts where you want types but not a compile step
• Legacy codebases that can't afford a full TypeScript migration
• Libraries that want to ship types without requiring consumers to use TypeScript

The downside: the syntax is verbose, generics are awkward to express in JSDoc, and you lose the clarity of .ts syntax. It's a half-measure that makes sense when a full measure isn't feasible.

When to Use TypeScript

• Any codebase more than one developer will touch
• Anything that talks to an external API (the response shapes change; TypeScript catches the mismatch)
• Any project you'll maintain for more than a few months
• React, Next.js, Nuxt, SvelteKit, Astro — all ship TS-first defaults for a reason
• npm packages that other developers will consume (they get types for free)
• Anything where renaming a function across 20 files needs to be safe

When to Use JavaScript

• A script you'll run once or twice
• Learning web development fundamentals (types add cognitive load before the basics are solid)
• A throwaway prototype that will never see production
• A 30-line automation script where tsc --init is more work than the script itself

When to Use Both

In practice, large codebases often mix them: TypeScript for application code, plain JavaScript for build scripts, one-off tooling, and configuration files that run outside the build pipeline.

The allowJs: true compiler option lets TypeScript and JavaScript files coexist. New files go in as .ts, old files stay as .js until there's time to migrate.

TypeScript is the default for serious JavaScript work in 2026 — the tooling caught up, the framework defaults changed, and the AI coding tools swung the DX argument decisively. The remaining question isn't "should we use TypeScript" but "which parts don't need it." The answer is usually: quick scripts and throwaway tools. Everything else benefits.

The userId bug in the opening PR would have been a red squiggle on line 2.