TypeScript vs JavaScript in 2026: The Trade-off Just Changed

For a decade the case against TypeScript rested on two practical complaints: it's slow, and it needs a build step. Both got substantially weaker in the last eighteen months, and that changes the shape of the decision more than any new type-system feature has.

This guide covers what actually changed, what genuinely remains a trade-off, and how to decide — including the cases where plain JavaScript is still the right call.

What changed

TypeScript 7 is a native Go compiler

Microsoft announced TypeScript 7.0 on 8 July 2026 — a port of the compiler and language service from TypeScript to Go, developed under the codename Project Corsa.

The performance claims are unusually concrete. Microsoft reports build speedups typically between 8x and 12x, with memory use down 6–26% across tested codebases. Their headline example: type-checking the VS Code codebase dropped from 125.7 seconds to 10.6 seconds.

The gains come from two sources — native compilation instead of running the compiler on a JavaScript engine, and shared-memory parallelism across worker threads, which the JavaScript implementation couldn't do.

Node runs TypeScript without a build step

The other complaint — "TypeScript needs a build step" — has quietly stopped being true for backend code. Node.js type stripping removes type annotations and runs the resulting JavaScript directly.

The timeline: enabled by default in v23.6.0 and v22.18.0, marked stable in v25.2.0 and v24.12.0, with the --experimental-transform-types flag removed in v26.0.0. You can disable it with --no-strip-types.

# No tsc, no ts-node, no bundler
node server.ts

Node replaces type annotations with whitespace and runs the result. It does not type-check — that's still tsc's job. Type stripping is about execution, not verification.

Because it only erases syntax rather than generating code, anything requiring emitted JavaScript fails:

// These do NOT work under type stripping
enum Color { Red, Green }        // needs generated runtime object
namespace Foo { export const x = 1; }  // needs runtime code
class P { constructor(private x: number) {} }  // parameter properties

// These do work — erasable syntax only
import type { User } from "./types.ts";
import { fn, type FnParams } from "./fn.ts";

const x: number = 42;
function greet(name: string): string {
  return `Hello, ${name}`;
}

// Use a const object instead of an enum
const Color = { Red: "red", Green: "green" } as const;
type Color = typeof Color[keyof typeof Color];

TypeScript's erasableSyntaxOnly compiler option enforces this at type-check time, so you find out in your editor rather than at runtime. If you're writing new backend TypeScript, turning it on is a cheap way to keep the no-build-step option open.

What TypeScript actually buys you

Errors caught at the boundary

interface User {
  id: string;
  email: string;
  role: "admin" | "user" | "guest";
  createdAt: Date;
}

function canModerate(user: User): boolean {
  return user.role === "admin" || user.role === "moderator";
  //                              ~~~~~~~~~~~~~~~~~~~~~~~~
  // Error: This comparison appears unintentional because the types
  // '"admin" | "user" | "guest"' and '"moderator"' have no overlap.
}

That's the class of bug types are best at: a typo'd string in a branch you'd never have covered with a test. Union types turn "valid values" from documentation into something enforced.

Refactoring you can trust

This is the benefit that compounds and the one hardest to appreciate until you've felt it. Rename a field on a widely used interface and the compiler enumerates every site needing an update. Without it, you're grepping and hoping.

Signatures as documentation

function createUser(data: Omit<User, "id" | "createdAt">): Promise<User>;

That signature says: pass everything except id and createdAt, get a promise of a full User. No comment can go stale relative to it, because the compiler checks it.

Editor tooling

Autocomplete, jump-to-definition, and rename-symbol all work meaningfully better with type information. Notably, JavaScript developers benefit here too — editors run the TypeScript language service on plain JS.

What types don't catch

This is the section most TypeScript advocacy skips, and skipping it is how teams develop false confidence.

Types are erased at compile time. They do not exist at runtime. That means every value entering your program from outside — an API response, a JSON file, a form body, an environment variable, a database driver — is unchecked, no matter what you told the compiler.

// This annotation is a claim, not a check.
const user: User = await fetch("/api/user").then((r) => r.json());

// r.json() returns Promise<any>. TypeScript believes you.
// If the API returns { email: null }, this compiles and crashes at runtime.
console.log(user.email.toLowerCase());

That code type-checks perfectly and fails in production. The type annotation asserted a shape that nothing verified. This is the single most common way TypeScript codebases break, and it's why a type-safe application still needs runtime validation at its edges:

import { z } from "zod";

const User = z.object({
  id: z.string(),
  email: z.string().email(),
  role: z.enum(["admin", "user", "guest"]),
});

// Validated at runtime, and the static type is inferred from the schema
type User = z.infer<typeof User>;

const res = await fetch("/api/user");
const user = User.parse(await res.json()); // throws on unexpected shape

The rule that follows: validate at the boundary, trust within the core. Types are excellent for internal consistency and useless against a lying API. as casts and any punch holes in the same way — every cast is a place you've told the compiler to stop helping.

strict is where most of the value is

A tsconfig.json without strict: true delivers a fraction of the benefit. The most important flag inside it is strictNullChecks:

// Without strictNullChecks: compiles, throws at runtime
function getLength(s: string) { return s.length; }
getLength(null);

// With strictNullChecks: caught at compile time
// Error: Argument of type 'null' is not assignable to parameter of type 'string'

Null and undefined handling is the largest category of real bugs types can eliminate. A codebase running TypeScript without strict is paying most of the cost for a minority of the benefit — and if you're evaluating whether TypeScript "was worth it" on such a codebase, you're evaluating the wrong thing.

What JavaScript still gives you

A simpler mental model

No generics, no conditional types, no infer, no arguing about whether a helper type is too clever. For a 60-line script, TypeScript's ceremony is a real cost against a benefit you'll never collect.

No type-level rabbit holes

TypeScript's type system is Turing-complete and it's genuinely possible to lose an afternoon to a type error in code that would have worked fine. Anyone claiming this never happens hasn't maintained a large TypeScript codebase.

Universal compatibility

Plain JavaScript runs in every browser and runtime with no toolchain. For a snippet you paste into a console or a script in a CI job, that's the whole story.

Your dependencies decide how much this works

TypeScript's practical value depends heavily on the libraries you use, which is worth checking before you commit. Most significant packages now ship their own type definitions; older ones rely on community definitions from DefinitelyTyped, published as @types/* packages.

# Library ships its own types — nothing to install
npm install zod

# Types live separately, maintained by the community
npm install express
npm install -D @types/express

Two failure modes to know about. A community @types package can lag behind the library it describes, so the types claim one thing and the runtime does another. And an untyped dependency is implicitly any, which quietly disables checking wherever its values flow — one untyped module can hollow out the guarantees across a surprising amount of your codebase. noImplicitAny (part of strict) surfaces this rather than letting it pass silently.

The middle ground: JSDoc

You can get much of TypeScript's checking in .js files, with no build step and no syntax change:

// @ts-check

/**
 * @typedef {Object} User
 * @property {string} id
 * @property {string} email
 * @property {'admin' | 'user'} role
 */

/**
 * @param {Omit<User, 'id'>} data
 * @returns {Promise<User>}
 */
async function createUser(data) {
  // Fully type-checked. Still a .js file.
}

Add // @ts-check at the top of a file, or checkJs in tsconfig.json, and tsc --noEmit will check it. This is how several major libraries operate — full type safety internally, published .d.ts files for consumers, no compile step.

It's verbose, and complex generics get unpleasant fast. But for a mid-sized project unsure about committing, JSDoc is an honest middle path and an easy migration on-ramp.

Choosing

| Project type | Reasonable default | Why | |---|---|---| | Published npm library | TypeScript | Consumers expect .d.ts; your API is a contract | | Long-lived application | TypeScript | Refactoring safety compounds over years | | Multi-team codebase | TypeScript | Types are the interface between teams | | API backend | TypeScript | Request/response shapes are where bugs live | | Prototype validating an idea | JavaScript | It may not survive the week | | One-off script or glue code | JavaScript | Ceremony without payoff | | Learning to program | JavaScript | One thing at a time |

Two rows people get wrong. Serverless functions used to be listed as a JavaScript case because of cold starts — but types are erased at build time and don't exist at runtime, so a compiled TypeScript Lambda and a JavaScript one are the same JavaScript. Bundle size and cold start are unaffected. Performance-critical code is the same story: there is no runtime type checking, so there's no runtime overhead. Neither is a real argument.

The honest heuristic: will anyone, including future you, need to change this code without holding all of it in their head? If yes, types pay for themselves. If it's disposable or trivially small, they don't.

Types in JavaScript itself?

The TC39 type annotations proposal — "types as comments" — would let JavaScript engines parse and ignore type syntax, exactly as Node's type stripping now does.

// If this ever ships, it's just JavaScript
function greet(name: string): string {
  return `Hello, ${name}`;
}

Temper your expectations: it has been at Stage 1 since 2022, and Stage 1 means "worth exploring," not "coming soon." Its practical ideas arrived through Node's type stripping instead. Don't plan around it.

Migrating incrementally

You don't need a rewrite. TypeScript is designed for gradual adoption:

1. Add tsconfig.json with allowJs: true and strict: false.
2. Turn on checkJs — or add // @ts-check file by file — and fix what surfaces.
3. Rename files to .ts a module at a time, starting at the leaves.
4. Enable strict once the noise settles. strictNullChecks alone catches the largest real-bug category.
5. Consider erasableSyntaxOnly for backend code to keep the no-build-step path open.

Every step is independently useful, which is why "start in JavaScript, add types when it hurts" remains defensible advice.

The verdict

Default to TypeScript for anything you expect to maintain past a few months. The setup cost is now low, the compile-speed objection has largely evaporated with TypeScript 7, and the build-step objection is gone for backend code.

Use JavaScript without guilt for scripts, prototypes, and code that won't outlive the week — and know that JSDoc plus @ts-check sits between the two if you want checking without commitment.

The goal was never to pick the correct language. It's to match the tool to how long the code will live and how many people have to understand it.