TypeScript

JavaScript is dynamically typed. Variables have no declared type, function parameters carry no contract, and a function that expects a string will silently accept a number at runtime. This flexibility is useful in small scripts and harmful in large applications, where the absence of type information makes code difficult to reason about, refactor, and maintain.

TypeScript is a statically typed superset of JavaScript developed by Microsoft. It adds a type system, compiles to plain JavaScript, and introduces no runtime overhead. Every valid JavaScript file is also a valid TypeScript file.

What the Type System Provides#

Early error detection: Type mismatches, missing properties, and incorrect function calls are caught at compile time rather than discovered in production.

function greet(name: string): string {
    return "Hello, " + name.toUpperCase();
}

greet(42); // Error: Argument of type 'number' is not assignable to parameter of type 'string'

Null safety: With strict mode enabled, TypeScript tracks whether a value can be null or undefined and requires explicit handling before use.

function getLength(s: string | null): number {
    return s.length; // Error: Object is possibly 'null'
}

function getLength(s: string | null): number {
    return s?.length ?? 0; // Safe
}

Structural typing: TypeScript uses structural compatibility rather than nominal typing. If an object has the required shape, it satisfies the type—regardless of how it was declared.

interface Point {
    x: number;
    y: number;
}

function distance(a: Point, b: Point): number {
    return Math.sqrt((b.x - a.x) ** 2 + (b.y - a.y) ** 2);
}

distance({ x: 0, y: 0 }, { x: 3, y: 4 }); // Works—object literal satisfies Point

Refactoring support: Rename a function, change a parameter type, or restructure a data model, and the compiler immediately identifies every call site that needs updating. In a plain JavaScript codebase of any size, this is a manual and error-prone process.

Practical Implications#

TypeScript's type system is most valuable at boundaries: function signatures, API contracts, configuration shapes, and event payloads. These are where incorrect assumptions cause the most damage.

It is less useful as a substitute for runtime validation. TypeScript types are erased at runtime. A JSON response typed as User is not verified at the point it arrives from the network. Runtime validation libraries (Zod, Yup, Valibot) handle this separately.

Gradual Adoption#

TypeScript supports incremental migration. You can add TypeScript to an existing JavaScript project without converting everything at once. Start by renaming files to .ts, fix the errors the compiler reports, and progressively enable stricter checks as the codebase stabilizes. The compiler's --allowJs flag enables coexistence of .js and .ts files during the transition.

Tooling#

TypeScript has first-class support in most editors. In VS Code, type information powers autocompletion, inline documentation, refactoring operations, and real-time error highlighting. This is not incidental—it is one of the primary reasons TypeScript was built.

Conclusion#

TypeScript's value is proportional to the size and lifetime of the codebase. For a script that runs once, the overhead is not justified. For an application that will be maintained by multiple developers over years, the type system pays consistent dividends: fewer runtime surprises, safer refactoring, and code that documents its own contracts.

Enable strict mode from the start. Avoid any where possible. Use types at boundaries. The discipline compounds over time.